--- 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?
