Date: Wed, 22 Apr 2020 20:45:59 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 245765] inetd doesn't cleanup his PID file Message-ID: <bug-245765-227-3VPGRyuPFS@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-245765-227@https.bugs.freebsd.org/bugzilla/> References: <bug-245765-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245765 Jason A. Harmening <jah@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jah@FreeBSD.org --- Comment #1 from Jason A. Harmening <jah@FreeBSD.org> --- 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. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-245765-227-3VPGRyuPFS>