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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245765 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 w= ill 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 t= he 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 lock= s or interfere with concurrent startup of a new instance of the service. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-245765-227-3VPGRyuPFS>