https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245765
Jason A. Harmening <j...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |j...@freebsd.org
--- Comment #1 from Jason A. Harmening <j...@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.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
