Package: debian-faq Section 11.5/11.6 - Replace Boot-up method from init to systemd.
Proposed change in patch file attached.
--- customizing.sgml 2015-05-29 14:15:36.792753648 +0800 +++ customizing.sgml.new 2015-05-29 15:08:09.037752850 +0800 @@ -52,96 +52,32 @@ <sect id="booting">Every distribution seems to have a different boot-up method. Tell me about Debian's. -<p>Like all Unices, Debian boots up by executing the program <tt>init</tt> -<footnote>As of this writing, the unstable release for Debian GNU/Linux is -replacing sysvinit with <prgn/systemd/, a system and service manager for Linux. For -more information see <url id="https://wiki.debian.org/systemd";>.</footnote>. -The configuration file for <tt>init</tt> (which is <tt>/etc/inittab</tt>) -specifies that the first script to be executed should be -<tt>/etc/init.d/rcS</tt>. This script runs all of the scripts in -<tt>/etc/rcS.d/</tt> by forking subprocess -to perform initialization such as to check and to mount file systems, -to load modules, to start the network services, to set the clock, and to -perform other initialization. - -<p>After completing the boot process, <tt>init</tt> executes all start -scripts in a directory specified by the default runlevel (this runlevel -is given by the entry for <tt>id</tt> in <tt>/etc/inittab</tt>). -Like most <!-- all? SGK --> System V compatible Unices, Linux has 7 runlevels: -<list> - <item>0 (halt the system), - <item>1 (single-user mode), - <item>2 through 5 (various multi-user modes), and - <item>6 (reboot the system). -</list> -Debian systems come with id=2, which indicates that the default -runlevel will be '2' when the multi-user state is entered, and the -scripts in <tt>/etc/rc2.d/</tt> will be run. - -<p>Debian uses dependency-based boot ordering through <prgn/insserv/, using the -LSB headers in each script under <tt>/etc/init.d/</tt>, as well as -parallel concurrent booting through the use of <prgn/startpar/ to speed -up the boot process. - -<p>The scripts in any of the directories, <tt>/etc/rcN.d/</tt> -are just symbolic links back to scripts in <tt>/etc/init.d/</tt>. However, -the <em>names</em> of the files in each of the <tt>/etc/rcN.d/</tt> -directories are selected to indicate the <em>way</em> the scripts in -<tt>/etc/init.d/</tt> will be run. Specifically, before entering any -runlevel, all the scripts beginning with 'K' are run; these scripts kill -services. Then all the scripts beginning with 'S' are run; these scripts -start services. The two-digit number following the 'K' or 'S' indicates -the order in which the script is run. Lower numbered scripts are executed -first. - -<p>This approach works because the scripts in <tt>/etc/init.d/</tt> all -take an argument which can be either `start', `stop', `reload', `restart' -or `force-reload' and will then do the task indicated by the argument. -These scripts can be used even after a system has been booted, to control -various processes. - -<p>For example, with the argument `reload' the command - <example>/etc/init.d/sendmail reload</example> -sends the sendmail daemon a signal to reread its configuration file. - -<p>Note that <prgn/invoke-rc.d/ should not be used to call the -<tt>/etc/init.d/</tt> scripts, <prgn/service/ should be used instead. - -<sect id="custombootscripts">What other facilities are provided - to customize the boot process besides - <tt>rc.local</tt>? - -<p>The <tt>rc.local</tt> script is executed at the end of each multiuser -runlevel. In Debian it is configured to do nothing. This provides -customisation of the boot process, but might not be sufficient -for all situations. - -<p>Suppose a system needs to execute script <tt>foo</tt> on start-up, -or on entry to a particular (System V) runlevel. Then the system -administrator should: -<list> - <item>Enter the script <tt>foo</tt> into the directory <tt>/etc/init.d/</tt>. - <item>Run the Debian command <tt>update-rc.d</tt> with appropriate - arguments, to specify which runlevels should start the service, and which - runlevels should stop the service. - <item>Consider rebooting the system to check that the service starts - correctly (assuming that you've asked for it to be started in the - default runlevel). Otherwise, manually start it by running - `<tt>/etc/init.d/foo start</tt>'. -</list> - -<p>One might, for example, cause the script <tt>foo</tt> to execute at -boot-up, by putting it in <tt>/etc/init.d/</tt> and running -<tt>update-rc.d foo defaults 19</tt>. The argument `<tt>defaults</tt>' refers -to the default runlevels, which means (at least in absence of any LSB comment -block to the contrary) to start the service in runlevels 2 through 5, -and to stop the service in runlevels 0, 1 and 6. -(Any LSB Default-Start and Default-Stop directives in <tt>foo</tt> take -precedence when using the sysv-rc version of update-rc.d, but are -ignored by the current (v0.8.10) file-rc version of update-rc.d.) -The argument `<tt>19</tt>' ensures that <tt>foo</tt> is called after all -scripts whose number is less than 19 have completed, and before all scripts -whose number is 20 or greater. +<p>Like most Linux distributions, Debian boots up by executing the program +<tt>systemd</tt>. Systemd provides the concept of targets similar to runlevel +which was found from Unices and previous version of Debian GNU/Linux. You may +check the default target by the command + + <example>systemctl get-default</example> + +<p>During boot-up, systemd start the services or other targets listed in the +default target file <tt>/lib/systemd/system/default.target</tt>. These +services and targets files are installed during Debian package installation. +If you explicitly do not wish to run the services during boot-up, instead of +remove the installed package, you can run the command + + <example>systemctl disable package.service</example> + +<p>where package.service is the services files installed in +<tt>/lib/systemd/system</tt>. + +<p>Service file <tt>/lib/systemd/rc.local.service</tt> provides an easy way to +run customized scripts in the file <tt>/etc/rc.local</tt> after boot-up +complete to ease the system upgrade from old version using <tt>init</tt>. +While this script will fail if it has interaction to the console such as +asking user password or clear the screen. You can check the status of any +service by the command + + <example>systemctl status package.service</example> <sect id="interconffiles">How does the package management system deal with packages that contain configuration files for other packages?
