Xinetd flags questions

Discussion in 'Linux Networking' started by tibo, Feb 2, 2004.

  1. tibo

    tibo Guest

    Hello people !

    I'm working on xinetd and I need light on the meaning of some flags of
    /etc/xinetd.conf and I hope someone can answer me.

    NORETRY
    Avoid retry attempts in case of fork failure.

    I think this sentence is not clear. Can someone explain me what is a fork in
    this case (I've understood the a fork is a creation of new identical
    process) ?

    What are the possible causes of a fork failure ?

    And finally, "Avoid retry Attempts" of what ? of connecting ?

    This is the way I've understood the stuff. When, for some reason, it's been
    impossible for xinetd to launch a server, it won't try again. Am I right ?

    INTERCEPT
    Intercept packets or accepted connections in order to verify that they are
    coming from acceptable locations (internal or multi-threaded services cannot
    be intercepted).

    I've enabled this flag to try, and add the ONLY_FROM attribute.
    I have seen that, whether INTERCEPT is activated or not, ONLY_FROM works and
    if I have not the good address as specified in ONLY_FROM, I won't connect,
    even if INTERCEPT is not set.

    I thought I needed to activate INTERCEPT to make ONLY_FROM work. Do I miss
    something ?

    WAIT

    Just a little question about that, I've understood the aim of WAIT was the
    prevent the creation of a new instance when a connexion is active, ie there
    can be only one connexion at a time. I tried to activate it with telnetd.
    When It's activated, I can't even connect once. Is there any reasons ?

    Thank you a lot for your answers to that bunch of questions :) !
     
    tibo, Feb 2, 2004
    #1
    1. Advertisements

  2. tibo

    Cameron Kerr Guest

    Its quite clear if you understand what fork(2) does. What its saying is
    that if a call to fork() fails, perhaps because there are insufficient
    resources, then it won't try to start it again later. Normally, xinetd
    will service that port in a loop, starting the appropriate server for
    the connection. This option enables a fail-safe test that breaks out of
    that loop.
    According to the fork(2) manual page, they are thus.

    EAGAIN

    fork cannot allocate sufficient memory to copy the parent's page
    tables and allocate a task structure for the child.

    ENOMEM

    fork failed to allocate the necessary kernel structures because
    memory is tight.

    You may get EAGAIN if the user the process is running under exceeds
    their process limit (man ulimit for more information about that).
    Of servicing.
    Not entirely (at least, not according to the documentation above). When
    it fails to create the new process (that's not starting the new process,
    that is done with exec(2))
    This would probably be more useful for UDP based servers, as TCP servers
    usually use TCP-Wrappers to do access control. Because of how inetd
    style services work, (x)inetd does the accepting of the connection, and
    the daemon it starts reads from stdin (though it can treat it just like
    a network socket). With UDP services, the daemon uses recvfrom(2) on
    stdin to get the data from the network.

    It would appear that INTERCEPT would make it so xinetd reads the network
    bytestream/datagrams check their addresses, and then, if thay are okay,
    forward then to the descriptor that is connected to stdin of the daemon.
    Perhaps it is addition to hosts.{allow,deny}? I haven't really used
    xinetd myself, but perhaps you should post the general and service
    specific parts of your xinetd configuration, and the contents of your
    hosts.{allow,deny}
    Did you cause xinetd to reload itself (I know inetd uses HUP, but I have
    a sneaky suspicion that xinetd uses USR1 and USR2 signals). Perhaps just
    a "service xinetd reload" may help. (I'm guessing you're using RH based
    system, since you're using xinetd).

    Then, make sure that there is something listening on the port(s) in
    question. There are two tools I recommend for this, lsof, and the more
    ubiquitous netstat.

    netstat -atu

    Look for entries with "LISTENING" on the same line as "telnet"

    lsof -i

    Run it as root to get the information you need.
     
    Cameron Kerr, Feb 2, 2004
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.