Re: inetd tests failing

[Arjun <ccldarjun%icloud.com@localhost>]

> I wrote t_inetd.c as part of my senior project for college six months
> ago (as part of implementing some of the "inetd enhancements"
> project).
> It's most likely my fault it isn't working. t_inetd.c is quite fragile
> since it just uses a range of ports on the host machine.
> You could try checking if any of the TCP or UDP ports used in the test
> are in-use on your
> computer before the tests are run. I can also look into improving the
> test. But you can probably just ignore it for now.
The ports open on my laptop are 111 999 1017 1021 1023 2049 2222 51067 55780 59043 62799. 
These dont seem to be in the test. Could you run the test on your end?

> I think the "blacklist daemon" (now called "blocklist" in the next
> version) support might have been implemented as a single line in the
> Makefile (in this commit:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/inetd/Makefile?rev=1.24&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
> ),
> but I could be completely wrong. Maybe you've already talked to
> Christos Zoulas, but I think he would be the person to talk to for
> that.
I haven’t, yet, talked with him but I don't think simply linking with libblocklist will add that support?
I grepped for the blocklist functions (https://man.netbsd.org/NetBSD-9.2/blacklist.3 these are to notify
the blocklist daemon) in inetd source files and didn’t find any matches.

> My senior project group didn't get around to implementing
> "pre-forking", so that should be interesting to implement! Here's what
> Christos had
> to say about it: "Means that once a preforked child is done you can
> either wait(2) for it and end it or you can put it back of the list
> of available processes so that it can handle more requests." It's kind
> of a confusing concept to me!
Yeah, it does seem confusing to actually implement.

- Arjun