tags 787152 + patch thanks Hi,
Alan: thanks for reporting this issue; and for supplying the nice patch. See also https://lists.debian.org/<20160530145917.ge...@beskar.mdcc.cx> . (Working on this is still on my todo-list.) Bye, Joost On Fri, May 29, 2015 at 03:17:10PM +0800, Alan Lee wrote: > 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?
