Hello Robert,
Thursday, June 14, 2001, 11:39:37 PM, you wrote:
RW> 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?
RW> So, one of the things I've always hated (and loved) about UNIX is the pid
RW> system. One of the problems I have with (foo).pid is that pid's are
RW> rapidly recycled, so if a daemon dies, there's no way to track that unless
RW> you're a parent process (wherein you can reliably get the exiting
RW> information via SIGCHLD and wait()). The same goes for using killall as
RW> the superuser to find and kill processes such as inetd by name: you can
RW> easily kill other things if there are user processes with the same name,
RW> etc. In my view, the only really reliable way to manage daemon processes
RW> is as the parent of the process. Unfortunately, changing to that model
RW> would be a time-consuming, compatibility-limiting process which will
RW> probably not prove feasible.
RW> Just as an example of some potential suffering: suppose your system
RW> creates and destroyes about 200 processes a second, as it's a fairly
RW> heavily loaded user and web server. Such as system takes about five and a
RW> half minutes to recycle the pid space. If your sendmail daemon has pid
RW> 238 (or some other low pid), and dies, it takes about five minutes for
RW> some other process to adopt pid 238. However, /var/run/sendmail.pid will
RW> still contain 238, as it wasn't cleaned up due to untimely death. Sending
RW> a HUP signal to 238 could do a number of nasty things, including logging
RW> you out if it's your SSH daemon :-). Using IPC to manage the daemon, in
RW> the style of newer named versions, works well as long as you know the
RW> daemon is still functional--certainly much better than signals, with the
RW> exception of forceful termination.
RW> Robert N M Watson FreeBSD Core Team, TrustedBSD Project
RW> [EMAIL PROTECTED] NAI Labs, Safeport Network Services
My advice is:
Every scripts in rc.d has a status check function, for example:
"nfsd.sh status", if this command exits status 0 then it is runing
otherwise it is not running. let every script implements its own
method to detect if its daemon is up or down. rudely detect a
/var/run/${daemon}.pid file is just a typical way.
now every scripts should contains 3 functions:
start
stop
status
--
David Xu
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
