Date: Thu, 14 Jun 2001 11:39:37 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: "Koster, K.J." <K.J.Koster@kpn.com> Cc: Robert Withrow <bwithrow@nortelnetworks.com>, Cyrille Lefevre <clefevre@redirect.to>, freebsd-hackers@FreeBSD.ORG Subject: RE: import NetBSD rc system Message-ID: <Pine.NEB.3.96L.1010614113409.27518D-100000@fledge.watson.org> In-Reply-To: <59063B5B4D98D311BC0D0001FA7E452205FD9CAE@l04.research.kpn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Jun 2001, Koster, K.J. wrote:
> > To do some of the hierarchal start/stop at runtime stuff, you
> > really need
> > a stateful rc system that stores its start/stop state in
> > /var/run/rc.d or
> > the like. In this way, the system could track various
> > activities and know
> > which dependencies were already started.
>
> How about /var/run/{$deamon}.pid?
So, one of the things I've always hated (and loved) about UNIX is the pid
system. One of the problems I have with (foo).pid is that pid's are
rapidly recycled, so if a daemon dies, there's no way to track that unless
you're a parent process (wherein you can reliably get the exiting
information via SIGCHLD and wait()). The same goes for using killall as
the superuser to find and kill processes such as inetd by name: you can
easily kill other things if there are user processes with the same name,
etc. In my view, the only really reliable way to manage daemon processes
is as the parent of the process. Unfortunately, changing to that model
would be a time-consuming, compatibility-limiting process which will
probably not prove feasible.
Just as an example of some potential suffering: suppose your system
creates and destroyes about 200 processes a second, as it's a fairly
heavily loaded user and web server. Such as system takes about five and a
half minutes to recycle the pid space. If your sendmail daemon has pid
238 (or some other low pid), and dies, it takes about five minutes for
some other process to adopt pid 238. However, /var/run/sendmail.pid will
still contain 238, as it wasn't cleaned up due to untimely death. Sending
a HUP signal to 238 could do a number of nasty things, including logging
you out if it's your SSH daemon :-). Using IPC to manage the daemon, in
the style of newer named versions, works well as long as you know the
daemon is still functional--certainly much better than signals, with the
exception of forceful termination.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010614113409.27518D-100000>