[svlug] Editing Kubuntu/Linux runlevels

Rick Moen rick at linuxmafia.com
Mon Dec 19 13:01:53 PST 2005


Quoting Dan Martinez (dfm at razorwind.org):

> Interesting. Not an irrational way to go about things, but... does
> Debian proceed to do something interesting and/or clever with
> runlevels 3-5, having freed them up, or do they go unused?

Unused by default.  Here are the relevant comments from /etc/inittab:


  # Runlevel 0 is halt.
  # Runlevel 1 is single-user.
  # Runlevels 2-5 are multi-user.
  # Runlevel 6 is reboot.

...which are pretty unenlightening, come to think of it.  ;->

I hadn't looked at those other runlevels in a while:  Looks like I've
been unconsciously making them mirror /etc/rc2.d/ 's contents, as their
contents appear identical to its.

As a further comment on the earlier posts in this thread,
http://www.debian.org/doc/manuals/reference/ch-system.en.html clarifies:

  To disable the service, rename the symbolic link, so that its name
  begins with a K instead of with an S and its sequence number is 100
  minus xy.

  It is convenient to use a runlevel editor such as sysv-rc-conf or ksysv,
  for these purposes.

  It is possible to delete the S symlink for a service in a particular
  runlevel directory, instead of renaming it.  This does not disable the
  service, but leaves it in a "floating" state as far as the sysv-rc init
  system is concerned: on runlevel changes, the service will be neither
  started nor stopped, but will be left as it was, whether running or not
  running.  Note, however, that a service left in such a floating state
  will be started if its package is upgraded, whether or not it was running
  before the upgrade.  This is a known shortcoming of the current Debian
  system.  Note also that you should retain a service's K symlinks in
  runlevels 0 and 6.  If you delete all the symlinks for a service, then on
  upgrade the service's package will restore the symlinks to their factory
  default state.

  It is not advisable to make any changes to symlinks in /etc/rcS.d/. 





More information about the svlug mailing list