Re: Bug#164301: ITP: runit -- a UNIX init scheme with service supervision
On Mon, Oct 14, 2002 at 11:57:12AM +0200, Eduard Bloch wrote:
> * Gerrit Pape [Sun, Oct 13 2002, 09:57:59PM]:
> > daemontools package. run scripts, mostly starting daemons, must run in
> > the foreground. Currently controlling a service must be done manually,
> > runit provides a daemontools alike interface to do so.
>
> This method still sucks.
As far as my experience goes, this method elimates some of the well
known problems of the sysv init script system, e.g.:
o no guarantee on the process state for services
o how to reliably get the pid of a daemon?
o what if a daemon dies while the system is up?
o a blocking init script can stop the system from coming up
It additionally provides a great logging facility.
> What happened with those ideas about integrating or developing an init
> program that uses a dependency map between the init scripts, so the
> user can set priorities?! Ie. "start SSH as soon as possible,
> including all required prequisites (networking, hostname, firewall)"
> or "start mta, fetchmail and gettys as soon as possible, other things
> can run in background".
I never really did understand why such complex dependencies are needed.
This is just the startup of the machine, this happens rarely, process 1
runs the whole system's uptime, I would not add any code to process 1
for handling complex dependencies.
runit starts up the system with stage 1, the system's one time
initialization tasks (such as fsck, mount, network). Then it starts
stage 2 which doesn't return until system shutdown. Here are all system
services (such as getty, dns, mta, syslog, kernlog, ..) started in
parallel, and supervised. For each service you have an interface to get
the pid and status, and to send signals to the service. If a service
dies, it is restarted.
There is some documentation on the runit web page about how to implement
service dependencies on startup with run scripts, if you are interested.
Regards, Gerrit.
Reply to: