Xinetd flags questions

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 <(E-Mail Removed)> wrote:
> 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) ?

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.

> What are the possible causes of a fork failure ?

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).

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

Of servicing.

> 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 ?

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))

> 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).

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.

> 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.

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}

> 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 ?

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
(E-Mail Removed) : http://nzgeeks.org/cameron/
Empowered by Perl!