1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>runit - benefits</title>
</head>
<body>
<a href="http://smarden.org/pape/">G. Pape</a><br>
<a href="index.html">runit</a><br>
<hr>
<h1>runit - benefits</h1>
<hr>
<a href="#supervision">Service supervision</a><br>
<a href="#state">Clean process state</a><br>
<a href="#log">Reliable logging facility</a><br>
<a href="#fast">Fast system boot up and shutdown</a><br>
<a href="#portability">Portability</a><br>
<a href="#packaging">Packaging friendly</a><br>
<a href="#smallcode">Small code size</a>
<hr>
<i>runit</i>'s service concept is heavily based on the
<a href="http://cr.yp.to/daemontools.html">daemontools</a>' one, and mostly
compatible with it. The benefits described in the
<a href="http://cr.yp.to/daemontools/faq/create.html#why">daemontools faq</a>
also apply to <i>runit</i>'s service supervision.
Many of the benefits described here also apply to the
<a href="http://cr.yp.to/daemontools.html">daemontools</a> package.
Some are described in both places.
<hr>
<a name="supervision"><h3>Service supervision</h3></a>
Each service is associated with a <i>service directory</i>, and each
service daemon runs as a child process of a supervising
<a href="runsv.8.html">runsv</a> process running in this directory.
The <a href="runsv.8.html">runsv</a> program provides a reliable interface
for signalling the service daemon and controlling the service and supervisor.
Normally the <a href="runsvctrl.8.html">runsvctrl</a> program is used to
send commands through this interface.
The <a href="runsvstat.8.html">runsvstat</a> program can be used to print
status information about the service.
<p>
The <a href="runsv.8.html">runsv</a> program supervises the corresponding
service daemon.
By default a service is defined to be up, that means, if the service daemon
dies, it will be restarted.
Of course you can <a href="runsvctrl.8.html">tell runsv</a> otherwise.
<p>
You don't have such a control interface with <i>sysv init</i> for example.
Using the control interface to send signals to the service daemon saves a lot
of extra (non trivial) work to reliably find out the daemon's process id.
Also <i>sysv init</i> only supports 'respawning' of services started from
<tt>inittab</tt>.
<hr>
<a name="state"><h3>Clean process state</h3></a>
<i>runit</i> guarantees each service a clean process state, no matter if the
service is activated for the first time, reactivated, or simply restarted.
This means that the service always is started with the same environment,
resource limits, open file descriptors, and controlling terminals.
<p>
You don't necessarily have that with <i>sysv init</i> scripts for example.
It requires a carefully written init script that reliably cleans up and sets
the initial process state before starting the service daemon.
This adds even more complexity to the init script in comparison with a run
script used by <i>runit</i>.
Many of today's init scripts don't provide a clean process state, here is
an example on what could happen:
<pre>
# /etc/init.d/foo-daemon start
Starting foo daemon: food.
#
</pre>
Fine.
Everything works, nothing to worry about.
After rebooting the system this shows up on the screen:
<pre>
...
Starting foo daemon: food: command not found
failed.
...
</pre>
The <tt>food</tt> program is installed in <tt>/opt/foo/bin/</tt>. When
starting the service for the first time using the init script, the
<tt>PATH</tt> environment variable contained <tt>/opt/foo/bin</tt>.
After reboot <tt>init</tt> started the service using the init script, but
with a different value for the <tt>PATH</tt> variable, not containing
<tt>/opt/foo/bin</tt>.
Of course the init script should have set <tt>PATH</tt> before starting the
daemon; the problem is that it worked in the first place, and that the error
didn't show up until system reboot.
<p>
With bad init scripts miraculous things could also happen when just doing
<pre>
# /etc/init.d/foo-daemon restart
</pre>
at the command line.
<hr>
<a name="log"><h3>Reliable logging facility</h3></a>
The <a href="runsv.8.html">runsv</a> program provides a reliable logging
facility for the service daemon.
If configured, <a href="runsv.8.html">runsv</a> creates a pipe, starts and
supervises an additional log service, redirects the log daemon's standard
input to read from the pipe, and redirects the service daemon's standard
output to write to the pipe.
Restarting the service does not require restarting the log service.
A good choice for a log daemon is <i>runit</i>'s service logging daemon
<a href="svlogd.8.html">svlogd</a>, or
<a href="http://cr.yp.to/daemontools/multilog.html">multilog</a> from the
<i>daemontools</i> package.
<p>
The service daemon and the log daemon can run with different process states,
and under different user id's.
<i>runit</i> supports easy and reliable logging for service daemons running
chroot'ed.
<p>
If <a href="runsv.8.html">runsv</a> is told to shutdown a service, e.g. at
system shutdown, it ensures that the log service stays up as long as the
corresponding service daemon is running and possibly writing to the log.
<hr>
<a name="fast"><h3>Fast system boot up and shutdown</h3></a>
After the system's one time tasks (stage 1) are done, the system services
are started up in parallel.
The operating system's process scheduler takes care of having the services
available as soon as possible.
<p>
On system shutdown, stage 3 uses <a href="runsv.8.html">runsv</a>'s control
interface to wait until each service daemon is terminated and all logs are
written.
Again, services are taken down in parallel.
As soon as all services are done, system halt or system reboot is initiated.
<hr>
<a name="portability"><h3>Portability</h3></a>
<i>runit</i> comes ready-to-run for Debian GNU/Linux and BSD systems, and
can easily be configured to run on other UNIX systems.
The UNIX system's one time initialization tasks and tasks to shutdown the
system must be identified and <i>runit</i>'s stages 1 and 3 configured
accordingly.
<p>
Stages 1 and 3 handle one time tasks.
They only run for short and exit soon.
Stage 2 handles the system's uptime tasks (via the
<a href="runsvdir.8.html">runsvdir</a> program) and is running the whole
system's uptime.
<p>
<i>runit</i>'s stage 2 is portable across UNIX systems.
<i>runit</i> is well suited for server systems and embedded systems, and
also does its job well on desktop systems.
<hr>
<a name="packaging"><h3>Packaging friendly</h3></a>
<i>runit</i>'s stages 1 and 3 are distribution specific.
They are shell scripts, and an operating system distribution with software
package management should adapt these scripts if they need support for their
package management.
The
<a href="http://packages.debian.org/unstable/admin/runit-run.html">
runit-run</a>
Debian package is an attempt to integrate <i>runit</i> into
<a href="http://www.debian.org/">Debian GNU/Linux</a> as an alternative to
the default
<a href="http://packages.debian.org/unstable/base/sysvinit.html">
sysvinit</a>.
<p>
Stage 2 already is packaging friendly:
all a software package that provides a service needs to do is to include
a <i>service directory</i> in the package and to provide a symbolic link
to this directory in <tt>/service/</tt>.
The service will be started within five seconds.
The package's install and update scripts can use the reliable control
interface to stop, start, restart, or send signals to the service.
On package removal, the symbolic link simply is removed.
<hr>
<a name="smallcode"><h3>Small code size</h3></a>
One of the <i>runit</i> project's principles is to keep the code size
small. As of version 0.8.0 of <i>runit</i>, the <tt>runit.c</tt>
source contains only about 300 lines of code; the <tt>runsvdir.c</tt>
source is also about 300 lines of code, the <tt>runsv.c</tt> source about
500.
This minimizes the possibility of bugs introduced by programmer's fault,
and makes it more easy for security related people to proofread the source
code.
<p>
The <i>runit</i> programs have a very small memory footprint and do not
allocate memory dynamically.
<hr>
<address><a href="mailto:pape@smarden.org">
Gerrit Pape <pape@smarden.org>
</a></address>
<small>$Id$</small>
</body>
</html>
|
