When a service has a maximum number of children configured in inetd.conf, I have found that, when the service exits due to a signal or with a non-zero exit status, that inetd will print to the syslog with something like: inetd[15005]: /usr/libexec/telnetd[15008]: exited, status 1 If no maximum number of children is configured for a service, then this doesn't occur. Fix: I looked at the source and found that se_maxchild is being checked in addchild(): void addchild(struct servtab *sep, pid_t pid) { if (sep->se_maxchild <= 0) <---- return; [...] sep->se_pids[sep->se_numchild++] = pid; [...] This is the only place that se_numchild gets incremented. se_numchild is used later on in logic in reapchild() to print out the above message. If se_maxchild is 0 (never set in inetd.conf), then addchild() never gets to increment se_numchild, and the logic in reapchild() is such that the message never gets printed. I think a simple change in reapchild() to not rely on se_maxchild when printing should solve this problem. How-To-Repeat: Configure inetd.conf to have a finite maximum number of children for a service, and then execute and exit the service.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
A commit references this bug: Author: kevans Date: Wed Jan 1 04:22:05 UTC 2020 New revision: 356247 URL: https://svnweb.freebsd.org/changeset/base/356247 Log: inetd: track all child pids, regardless of maxchild spec Currently, child pids are only tracked if maxchildren is specified. As a consequence, without a maxchild limit we do not get a notice in syslog on children aborting abnormally. This turns out to be a great debugging aide at times. Children are now tracked in a LIST; the management interface is decidedly less painful when there's no upper bound on the number of entries we may have at the cost of one small allocation per connection. PR: 70335 Changes: head/usr.sbin/inetd/inetd.c head/usr.sbin/inetd/inetd.h
Take; bug still valid only 15 years later, fix committed as r356247 will MFC in a week or so.