Re: inetd tests failing

[Solomon Ritzow <solduck%gmail.com@localhost>]

Hello Arjun,

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 changes my senior project group made previously are documented at
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/inetd/inetd.c?rev=1.127&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
and
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/inetd/inetd.c?rev=1.137&content-type=text/x-cvsweb-markup&only_with_tag=MAIN

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.

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!

Let me know if you have any questions or want to chat about inetd,
just send me an email. Especially since my senior project group did a
bunch of refactoring.

Sincerely,
Solomon Ritzow
solduck%gmail.com@localhost



On Mon, Mar 14, 2022 at 2:04 AM Arjun <ccldarjun%icloud.com@localhost> wrote:
>
> Hello NetBSD community,
>         I am arjun and would like to participate in Google’s Summer of Code 2022. I’ve always wanted to participate in open source work and am excited to start here :^)
>
>         The inetd enhancements project caught my eye, particularly the "pre-forking multiple children and keeping them alive for multiple invocations" milestone and "integration with the new bl(o/a)cklist daemon". At this time, I’m not entirely sure about the details of my proposal but...
>
>         So far, I’ve got a 9.1 vagrant box (https://app.vagrantup.com/NetBSD/boxes/NetBSD-9.1), and the latest stable version of inetd built and running. I ran the inetd tests and it is failing:
>
> $ make; sudo atf-run
> tps-count: 1
> tp-start: 1647084348.965492, t_inetd, 1
> tc-start: 1647084348.965587, test_ratelimit
> tc-se:ADD : 5432 proto=protocol, wait.max=0.40, user:group=udp,:(null) builtin=0 server=wait policy=
> tc-se:ADD : 5433 proto=protocol, wait.max=0.40, user:group=udp,:(null) builtin=0 server=wait policy=
> tc-se:ADD : 5434 proto=protocol, wait.max=0.40, user:group=udp,:(null) builtin=0 server=wait policy=
> tc-se:ADD : 5435 proto=protocol, wait.max=0.40, user:group=udp,:(null) builtin=0 server=wait policy=
> tc-se:REDO: 5434 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:REDO: 5435 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:ADD : 5436 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:ADD : 5437 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:ADD : 5438 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:ADD : 5439 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:FREE: 5439 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:FREE: 5438 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:FREE: 5437 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:FREE: 5436 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:FREE: 5435 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:FREE: 5434 proto=protocol, wait.max=0.40, user:group=tcp,:(null) builtin=0 server=wait policy=
> tc-se:FREE: 5433 proto=protocol, wait.max=0.40, user:group=udp,:(null) builtin=0 server=wait policy=
> tc-se:FREE: 5432 proto=protocol, wait.max=0.40, user:group=udp,:(null) builtin=0 server=wait policy=
> tc-end: 1647084350.985734, test_ratelimit, failed, t_inetd.c:103: run_udp_client("5432") not met
> tp-end: 1647084350.986304, t_inetd
>
> The recvmsg call is failing with EAGAIN, which means it is timing out. Is this test supposed to fail with the current state of inetd? Or, is my current setup improperly configured?
>