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

[Mats Erik Andersson]

Dear Ludovic,

you pose good questions which we need to discuss.

torsdag den  4 november 2010 klockan 00:03 skrev Ludovic Courtès detta:
> Hello,
> 
> Mats Erik Andersson <address@hidden> writes:
> 
> [...]
> 
> >> > +# Check that the port is still available
> >> > +netstat -na | grep -q "^$PROTO .*$PORT "
> >> > +if test $? -eq 0; then
> >> > +    echo "Desired port $PORT/$PROTO is already in use."
> >> > +    exit 1
> >> > +fi
> >> 
> >> This breaks because ???netstat??? may not be in $PATH; in particular, it
> >> breaks the Hydra builder: <http://hydra.nixos.org/build/727555>.
> >
> > True. Will be changed.
> 
> Now, ???netstat??? isn???t provided by Inetutils, so it???ll have to be
> ???AC_PATH_PROG???d, and the test will have to be skipped if it isn???t
> found.

In my view a test program is not part of a software distribution.
It is there to provide a tool, and a also a demonstration in what
ways a piece of software has been tested, for the verification
that the intended services behave as they were conceived.

You are right about skipping. Write a patch suggestion! The trivial
one needs more context:

   test -x netstat  ||  exit 1

No critisism intended!

> 
> Furthermore, it may be that not all ???netstat??? implementations behave
> equally.  On GNU/Linux ???netstat??? is typically the one provided in Linux
> net-tools; does it behave the same as on OpenBSD, etc.?

Exactly, that is why I had to produce a further patch, which already
has been sent to the mailing list. The difficulty here was that
either of "udp", "udp4", and "udp46" are possible designations. This
I overlooked in the first version. It must be an iterative proceedure
to establish this. The very first issue of "tftp.sh" failed completely
for OpenBSD. I had fixed that and submitted, only to find that this
fix failed for FreeBSD and GNU/kFreeBSD once I booted such systems,
so I had to proceed to mend that also.

> 
> >> Furthermore, I think it???s useless: if ???inetd??? fails to listen on 
> >> $PORT,
> >> the remainder of the script will notice it anyway.
> >
> > Not at all. How do you then tell which part was failing: Inetd or Tftpd.
> 
> For ???tftp.sh???, it doesn???t matter which one is failing.  It???s a 
> tftp{,d}
> test.  If something fails on the way, what matters is that the test
> actually fails.

I maintain my view point: It must at every time be possible to tell
exactly why a test fail. Was it due to the object under test, or was
it due to failer of the used tools?
> 
> However, I agree that ???inetd??? alone should be tested as well.  There???s
> should be a different test for that, ideally a lower-level one, possibly
> treating ???inetd??? as a white box.

I agree again. Inetd must _also_ have its own test, but as long as
the tests are written as individual entities, it misses the target
to assume the correctness of each product of Inetutils that is being
used as a tool in a test. On the other hand, any tool from the running
OS should be assumed correct, but the test machinery must in an iterative
process be used in as many possible environments that differing output
from differing implementations be taken care of.


> 
> >> > +# 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!
> 
> 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".
Remember my harsh talk about robustness?

As a side note, you may have noted that in computing ADDRESSES,
I have abondoned '\+' for '\{1,}'. That was motivated by a peculiarity
of "sed" in OpenBSD. As far as I know, '\+' is a peculiarity of GNU sed!
At least, that is the content of a table in O'Reilley's "Linux in"
a nutshell".

I am unhappy that "inetd" now is very verbose even wothout "VERBOSE=1",
but without "-d" I could not track the listening process the way you
originally did. Besides, the original script left me of exactly the
reason mention above, with eight live inetd-processes while doing
initial testing in OpenBSD. Then I bagan to see the weak ingredients.

I would very much welcome alterations to eliminate those irritating
messages in non-verbose mode, but I find myself having more urgent
business to attend to.

Personally I do appreciate your concern to pin point the test suite.
Had it not been for your initiative in writing a clearly useful
tool, I would probably not I thought of it for another month.

NixOS is unknown territory for me, but I aim at all POSIX systems,
so tell me and tell the project all objections and all alterations
wishes you can detect. The GNU code is intended to useable almost
everywhere. Right?

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.


Best regards and in appreciation,

Mats E A