blog/data/2011-08-04-rcS.txt

   1 Title: How is booting into runlevel 1 different from single user boots?
   2 Tags: english, debian, bootsystem
   3 Date: 2011-08-04 12:40
   4
   5 <p>Wouter Verhelst have some
   6 <a href="http://grep.be/blog/en/retorts/pere_kubuntu_boot">interesting
   7 comments and opinions</a> on my blog post on
   8 <a href="http://www.hungry.com/~pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html">the
   9 need to clean up /etc/rcS.d/ in Debian</a> and my blog post about
  10 <a href="http://www.hungry.com/~pere/blog/What_is_missing_in_the_Debian_desktop__or_why_my_parents_use_Kubuntu.html">the
  11 default KDE desktop in Debian</a>.  I only have time to address one
  12 small piece of his comment now, and though it best to address the
  13 misunderstanding he bring forward:</p>
  14
  15 <p><blockquote>
  16 Currently, a system admin has four options: [...] boot to a
  17 single-user system (by adding 'single' to the kernel command line;
  18 this runs rcS and rc1 scripts)
  19 </blockquote></p>
  20
  21 <p>This make me believe Wouter believe booting into single user mode
  22 and booting into runlevel 1 is the same.  I am not surprised he
  23 believe this, because it would make sense and is a quite sensible
  24 thing to believe.  But because the boot in Debian is slightly broken,
  25 runlevel 1 do not work properly and it isn't the same as single user
  26 mode.  I'll try to explain what is actually happing, but it is a bit
  27 hard to explain.</p>
  28
  29 <p>Single user mode is defined like this in /etc/inittab:
  30 "<tt>~~:S:wait:/sbin/sulogin</tt>".  This means the only thing that is
  31 executed in single user mode is sulogin.  Single user mode is a boot
  32 state "between" the runlevels, and when booting into single user mode,
  33 only the scripts in /etc/rcS.d/ are executed before the init process
  34 enters the single user state.  When switching to runlevel 1, the state
  35 is in fact not ending in runlevel 1, but it passes through runlevel 1
  36 and end up in the single user mode (see /etc/rc1.d/S03single, which
  37 runs "init -t1 S" to switch to single user mode at the end of runlevel
  38 1.  It is confusing that the 'S' (single user) init mode is not the
  39 mode enabled by /etc/rcS.d/ (which is more like the initial boot
  40 mode).</p>
  41
  42 <p>This summary might make it clearer.  When booting for the first
  43 time into single user mode, the following commands are executed:
  44 "<tt>/etc/init.d/rc S; /sbin/sulogin</tt>".  When booting into
  45 runlevel 1, the following commands are executed: "<tt>/etc/init.d/rc
  46 S; /etc/init.d/rc 1; /sbin/sulogin</tt>".  A problem show up when
  47 trying to continue after visiting single user mode.  Not all services
  48 are started again as they should, causing the machine to end up in an
  49 unpredicatble state.  This is why Debian admins recommend rebooting
  50 after visiting single user mode.</p>
  51
  52 <p>A similar problem with runlevel 1 is caused by the amount of
  53 scripts executed from /etc/rcS.d/.  When switching from say runlevel 2
  54 to runlevel 1, the services started from /etc/rcS.d/ are not properly
  55 stopped when passing through the scripts in /etc/rc1.d/, and not
  56 started again when switching away from runlevel 1 to the runlevels
  57 2-5.  I believe the problem is best fixed by moving all the scripts
  58 out of /etc/rcS.d/ that are not <strong>required</strong> to get a
  59 functioning single user mode during boot.</p>
  60
  61 <p>I have spent several years investigating the Debian boot system,
  62 and discovered this problem a few years ago.  I suspect it originates
  63 from when sysvinit was introduced into Debian, a long time ago.</p>