CVS commit: [netbsd-11] src/tests/usr.sbin/inetd

Module Name:	src
Committed By:	martin
Date:		Sat Jun 27 10:58:28 UTC 2026

Modified Files:
	src/tests/usr.sbin/inetd [netbsd-11]: t_accept_max.sh

Log Message:
Pull up following revision(s) (requested by riastradh in ticket #325):

	tests/usr.sbin/inetd/t_accept_max.sh: revision 1.3
	tests/usr.sbin/inetd/t_accept_max.sh: revision 1.4

inetd(8): Fix sh(1) trap save/restore in accept-max test.

Fixes mysterious
Failed: 1
failures like this one:
https://releng.netbsd.org/b5reports/i386/2026/2026.06.22.22.27.17/test.html#usr.sbin_inetd_t_accept_max_max2_kv

PR bin/59645: inetd `rate-limiting' algorithm is stupid

tests/usr.sbin/inetd/t_accept_max: Handle SIGKRE.

Fix some cleanup issues and simplify according to most of kre's
suggestions.  Mostly this fixes the kill-background-jobs-on-trap
logic by not trying to kill the nonexistent %0, and killing each job
individually so `kill' doesn't stop early if one doesn't exist.

I'm keeping the idiom `: >foo' and `: <foo' because I think it's a
little clearer than a bare `>foo' or `<foo', and I'm keeping the -e
and -u on shell scripts (except the one-liners) because I want to get
early feedback as much as possible about unexpected failure modes --
even if it counterintuitively elides some feedback.
(I also generally use -o pipefail out of habit for the same reason
but I'll acquiesce to removing it here in a short script where there
are definitely no pipes.)

PR bin/59645: inetd `rate-limiting' algorithm is stupid


To generate a diff of this commit:
cvs rdiff -u -r1.2.2.2 -r1.2.2.3 src/tests/usr.sbin/inetd/t_accept_max.sh

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.