3rd Debian Conference System Init Scripts and the Debian O.S. Henrique de Moraes Holschuh∗ June 2002† Abstract Regardless of the kernel and bootstrapping method used, at the very end of a normal De- This paper describes the System V, OpenBSD / bian bootstrapping process the kernel will have FreeBSD, NetBSD and Debian 3.0 init script sys- mounted the real root le system in read-only tems. Some new proposals made by third-parties mode for us, and then it will execute /sbin/init, for init script systems are also described, with which will run with pid 1. emphasis on Richard Gooch's simpleinit sys- /sbin/init will then proceed to call the system tem. The system init script abstraction and policy init scripts, which will do the dirty job of mount- layer currently being deployed in Debian for the ing le systems in read-write mode, loading mod- release after 3.0 is described in detail. Changes to ules, starting service daemons, and running a lo- that abstraction layer are proposed to allow for gin shell for the user. dependency-based init script systems in Debian. In Debian, these init scripts live in /etc/init.d, and take one or more command-line parameters. 1 Linux System Bootstrap The rst parameter tells the init script which ac- tion it should take: start the service, stop the System bootstrapping procedures vary quite a bit, service, reload service conguration and so on. depending on which kernel is being used. With All other parameters are optional, and init-script- the imminent addition of the BSD kernels to De- dependent. The script will return exit status zero bian, we can expect the bootstrap procedures to if no errors occur, and non-zero otherwise. vary even more in the near future1. This init script command line convention is part For Linux kernels, the bootstrapping sequence of the System V init script architecture, which is depends on the existence of initrd images or com- Debian's default. Init scripts following this com- pressed RAM le system images, and even remote mand line convention and stored in /etc/init.d boot images. Debian uses at least three vari- will be called SysV-like init scripts2 in this paper. ants of Linux bootstrapping: initrd for our very big includes-even-the-kitchen-sink-as-modules 2.4 2 Init Script Systems kernel images; direct bootstrap for smaller 2.4 and 2.2 kernels, such as those normally created 2.1 System V by users of the kernel-package package; and com- pressed RAM le system for boot-oppies and The System V init script system is quite power- CD/DVDROMs. ful, and very adaptable due to its modular de- sign, true to System V style. This is a very big ∗ [email protected] † This is revision 1.16 of this document, advantage over the original BSD-like init script commited in 2nd July 2002, 12:01:34. 1 The Debian BSD eort will also introduce a new standard C library (libc), so system bootstrapping is the least of our worries. 2 SysV is the short form for System V. 1 systems3. Given the displeasure many have for Sysvinit is a fully-featured init as far as these some parts of the System V init script system, things go. Sysvinit can: this is a Very Good Thing, indeed: the modular design makes it possible to x what is bad, and • use a script to start every process it needs to keep what works ne. (/etc/initscript); The System V init script system is well under- deal with several system proles (runlevels), stood by most seasoned system administrators, • and switch between them upon user com- and well dened. It works mostly well with the mand; software packages concept, as long as they come from the same vendor. However, it is also messy • execute a congurable script to run the sys- and ungraceful, it is unintuitive, and it takes quite tem startup setup (/etc/init.d/rcS); a bit of maintenance to keep the init script exe- cution sequence just right. • babysit processes (restart, kill, control fork The init script system is composed rate), with dierent sets of processes for every of three modules: /sbin/init (Sysvinit), runlevel; /etc/init.d/rc (/etc/rc?.d/* symbolic link execute scripts on SIGPWR, SIGINT and farms) and the SysV-like system init scripts • kbrequest; themselves (/etc/init.d/* ). It has a concept of dierent system proles, • re-execute itself without bothering the rest of which are called runlevels. The runlevels are 0 the system; (system halt); 1 (single-user mode); 2, 3, 4 and 5 (normal modes)4; 6 (reboot system); 7, 8 and 9 • execute in system maintenance mode. These (normal but not normally used); and S (system are single-user mode (runs only the system startup). Runlevel S is only used during system startup scripts, and then run sulogin), and startup and allow single-user mode login. What emergency mode (only run sulogin); the other runlevels are used for varies from vendor change the runlevel init script subsystem (one to vendor, and sometimes even with the operating • can tell Sysvinit to run something other than system's version. /etc/init.d/rc to execute runlevel changes); 2.1.1 Sysvinit • deal with Linux serial consoles. Debian's default (and currently only) /sbin/init is Sysvinit currently cannot: the Linux System V init. It is packaged and main- tained both for Debian and upstream by Miquel deal directly with kernel ACLs8 (but patches 5 • van Smoorenburg . We shall call it Sysvinit. for Sysvinit to add such support, and patches 6 Sysvinit has a large memory footprint . On to the Linux kernel to work around Sysvinit's 7 an ia32 system, it takes about 1280 kibibytes limitations do exist). of virtual space, and 480 kibibytes of RSS. That 9 amounts to an itty-tiny bit of memory in these The default ACL inheritable set is empty KDE/GNOME days, but it is hardly what you in the mainline Linux Kernel (and also in De- would use for memory-starved embedded systems. bian's). Sysvinit needs to change that, or ACLs are eectively disabled without a ker- nel patch. It should also be able to modify 10 3 At least from the point of view of a distribution us- the capability bound set , so as to emulate ing a package-based system, anyway. 4 The runlevels the securelevel feature of the BSDs. are normally used in additive mode. For example: run- level 3 is runlevel 2 plus networking functions; runlevel 8 ACL is the short form for Access Control Lists. It is a 4 is runlevel 3 plus NFS and other remote services en- ne-grained permission control system, capable of limiting abled; runlevel 5 is runlevel 4 plus a X11 display server. even the superuser's access to the kernel. 9 Set of ACL 5 [email protected] 6 This is glibc's fault. Sysvinit permissions available to children of the current process. itself takes only 25 kibibytes. 7 A kibibyte is 1024 bytes 10 The capability bound set selects either superuser or ACL-based access control for every possible ACL. 2 • directly control processes that change their of the init script in /etc/init.d that the symbolic process group (as most daemons do); link points to14. The symbolic links are processed in shell colla- Usually only the rst limitation is of any im- tion order (which will be the one for the C locale portance, as daemons are controlled through init if one is lucky). First all K scripts are run with scripts instead of by Sysvinit. Debian will need the stop argument, then all S scripts are run with to address ACLs in a consistent way very soon: the start argument. Some /etc/init.d/rc scripts we already have the standard Linux kernel ACLs are known to try to optimize this a bit, and will (that cannot be used by default due to Sysvinit's not call a init script to start a service that should lack of ACL knowledge), and SE Linux11 is com- have been started in the previous runlevel and ing. We also have at least one ACL-aware le was not stopped in the current runlevel. Debian's system (xfs).12. The BSD kernels also have ACL- /etc/init.d/rc does just that. enabled extensions (Trusted BSD), which might One must make sure the scripts are numbered enter Debian one day. in the correct order. Scripts with the same num- ber are not guaranteed to always run in the same 2.1.2 Init scripts symbolic link farm deterministic order (due to locale collation rules, for example). The System V init script system decides which Right now, Debian does not take all the care services are to be started or killed in a given that such a fragile ordering enforcement system runlevel (or during a runlevel change) using the requires. Maintainers often select the wrong or- /etc/init.d/rc script. This information is stored dering numbers for their init scripts, and that will by symbolic link farms in directories, one direc- only get xed when someone notices it in her sys- tory per runlevel. To gure out if a service is sup- tem, and le a bug. Also, the default order num- posed to be started or stopped in a given runlevel, ber of 20 has too many services. one must inspect the correct link farm. The S runlevel is special, for Sysvinit is con- gured to run /etc/init.d/rcS at system startup.