Bug 245765 - inetd doesn't cleanup his PID file
Summary: inetd doesn't cleanup his PID file
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-20 14:14 UTC by Alexander Leidinger
Modified: 2020-04-22 20:45 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Leidinger freebsd_committer 2020-04-20 14:14:06 UTC
1. Start inetd (as a test you can enable "finger" in /etc/inetd.conf).
2. Stop inetd.
3. ls /var/run/inetd.pid   -> still there

If later the pids wrap around and another process is taking the pid of inetd, a new start may fail or a stop may kill an innocent process.
Comment 1 Jason A. Harmening freebsd_committer 2020-04-22 20:45:59 UTC
It's not just inetd that exhibits this behavior, you'll see the same thing for example with ntpd.

However, I don't think this is necessarily a functional issue. inetd/ntpd will not fail to restart if a prior pidfile is still present, they will simply update the pidfile to reflect the new process.  Furthermore, stopping these services will not kill an innocent process: rc.subr(8) will not terminate the process if ps(1) indicates the PID from the pidfile does not correspond to the expected executable.

The general philosophy seems to be that rc.subr will make use of a pidfile if one is present, but the creation and management of that pidfile is left up to the individual daemon.  For example, daemons that use pidfile(3) generally seem to remove the pidfile on termination, because pidfile_open() automatically locks the pidfile which makes this safe to do.   On the other hand, daemons that don't remove the pidfile also will not fail if the file is already present.  As such, it also isn't appropriate for rc.subr to automatically remove the pidfile on service termination, as that could break pidfile locks or interfere with concurrent startup of a new instance of the service.