Date: Fri, 15 Jun 2001 09:17:38 +0800 From: David Xu <bsddiy@163.net> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: "Koster, K.J." <K.J.Koster@kpn.com>, Robert Withrow <bwithrow@nortelnetworks.com>, Cyrille Lefevre <clefevre@redirect.to>, <freebsd-hackers@FreeBSD.ORG> Subject: Re[2]: import NetBSD rc system Message-ID: <1252069305.20010615091738@163.net> In-Reply-To: <Pine.NEB.3.96L.1010614113409.27518D-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1010614113409.27518D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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> robert@fledge.watson.org 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 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?1252069305.20010615091738>