bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-inetutils] Re: [PATCH] Inetd and test scripts


From: Ludovic Courtès
Subject: [bug-inetutils] Re: [PATCH] Inetd and test scripts
Date: Thu, 04 Nov 2010 15:12:31 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hi Mats,

Mats Erik Andersson <address@hidden> writes:

[...]

>> >> > +# Wait somewhat for the service to settle
>> >> > +sleep 1
>> >> 
>> >> Pointless.
>> >
>> > On the contrary, GNU/Linux was so quick to proceed that the test failed.
>> > Again, robustness and predictable behaviour.
>> 
>> Then we have a problem.  Under load, on a slower (virtual) CPU, etc., 1s
>> may not be enough.
>
> I had the race condition on Debian GNU/Linux testing/Squeeze with a
> processor Pentium III 800 MHz. Newer hardware is less likely. There
> was so far no race condition with OpenBSD on Pentium M, 1.73 MHz!

What I meant is that we need actual synchronization.

>> In daemon mode, I???d expect ???inetd??? would fork in the background only
>> once it???s read the config file and is actually listening where it needs
>> to.  If that is the case, then the ampersand can be removed and
>> synchronization should be perfect.  (That implies running inetd without
>> ???-d???.)
>> 
>> Speaking of which, why that:
>> 
>
>> -$INETD "${VERBOSE:+-d}" "$INETD_CONF" &
>> +$INETD -d "$INETD_CONF" &
>
> I expected and I was hoping to get this question!
>
> This is tricky. Without "-d" the backgrounding fails, and the use of
> the process number "$!" fails. Without "-d" Inetd will go into the
> background itself, and the shell dash/bash/ksh/csh/tcsh will in "$!"
> report the process number of the process that the shell in question
> used to spawn the process, not the intended process number of "inetd".

OK, understood.

[...]

> NixOS is unknown territory for me, but I aim at all POSIX systems,

NixOS is just another GNU/Linux distribution; the difference, which
makes it a demanding test environment, is that tools are installed in
“unusual” locations.  So any tool that’s not explicitly listed as a
dependency is effectively unavailable, as is the case with ‘netstat’.

> Let us cooperate in checking the test tools -- and Inetutils --
> for those operating systems available to us. My experience from
> these past months is, that prior to my new interest in GNU Inetutils
> nobody with easy access to OpenBSD could ever have aimed at POSIX
> far enough to also target this particular BSD form. It is only by
> diversity, the system dependencies are uncovered.

For the record Inetutils also gets built on FreeBSD and Darwin here:

  http://hydra.nixos.org/jobset/gnu/inetutils-master

Currently it fails to build on both, but apparently progress has been
made lately.  :-)

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]