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: /usr/libexec/telnetd: exited, status 1
If no maximum number of children is configured for a service, then this doesn't occur.
I looked at the source and found that se_maxchild is being checked in
addchild(struct servtab *sep, pid_t pid)
if (sep->se_maxchild <= 0) <----
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:
Date: Wed Jan 1 04:22:05 UTC 2020
New revision: 356247
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
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.
Take; bug still valid only 15 years later, fix committed as r356247 will MFC in a week or so.