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