Boot-Up Manager

 

Index

 

 

Introduction

The scripts located in /etc/init.d are part of the bootup sequence of every Debian-like distro. Very often Ubuntu's documentation and guides have suggested - in order to deactivate init scripts - to change the permissions of the scripts in /etc/init.d, making them non-executable. This will have the following consequences:

If the logic of a debian-like system boot up sequence is not very clear and familiar to you, you should not play with symlinks, permissions, etc. In order to avoid messing up your system, Boot-Up Manager will automate all of your configuration in a nice and clean graphical interface.

 

How bootup scripts work in Debian-based systems
0. Overview

All scripts executed by the init system are located in /etc/init.d. The directories /etc/rc?.d (? = S, 0 .. 6) contain relative links to those scripts. These links are named S<2-digit-number><original-name> or K<2-digit-number><original-name>.

If a script has the ".sh" suffix it is a bourne shell script and MAY be handled in an optimized manner. The behaviour of executing the script in an optimized way will not differ in any way from it being forked and executed in the regular way.

The following runlevels are defined:

N System bootup (NONE).
S Single user mode (not to be switched to directly)
0 halt
1 single user mode
2 - 5 multi user mode
6 reboot

1. Boot

When the systems boots, the /etc/init.d/rcS script is executed. It in turn executes all the S* scripts in /etc/rcS.d in alphabetical (and thus numerical) order. The first argument passed to the executed scripts is "start". The runlevel at this point is "N" (none).

Only things that need to be run once to get the system into a consistent state are to be run. The rcS.d directory is NOT meant to replace rc.local. One should not start daemons in this runlevel unless absolutely necessary. Eg, NFS might need the portmapper, so it is OK to start it early in the bootprocess. But this is not the time to start the squid proxy server.

2. Going multiuser

After the rcS.d scripts have been executed, init switches to the default runlevel as specified in /etc/inittab, usually "2". Init then executes the /etc/init.d/rc script which takes care of starting the services in /etc/rc2.d.

Because the previous runlevel is "N" (none) the /etc/rc2.d/KXXxxxx scripts will NOT be executed - there is nothing to stop yet, the system is busy coming up.

If for example there is a service that wants to run in runlevel 4 and ONLY in that level, it will place a KXXxxxx script in /etc/rc{2,3,5}.d to stop the service when switching out of runlevel 4. We do not need to run that script at this point.

The /etc.rc2.d/SXXxxxx scripts will be executed in alphabetical order, with the first argument set to "start".

3. Switching runlevels

When one switches from (for example) runlevel 2 to runlevel 3, /etc/init.d/rc will first execute in alphabetical order all K scripts for runlevel 3 (/etc/rc3.d/KXXxxxx) with as first argument "stop" and then all S scripts for runlevel 3 (/etc/rc3.d/SXXxxxx) with as first argument "start".

As an optimization, a check is made for each "service" to see if it was already running in the previous runlevel. If it was, and there is no K (stop) script present for it in the new runlevel, there is no need to start it a second time so that will not be done.

On the other hand, if there was a K script present, it is assumed the service was stopped on purpose first and so needs to be restarted.

We MIGHT make the same optimization for stop scripts as well, if no S script was present in the previous runlevel, we can assume that service was not running and we don't need to stop it either. In that case we can remove the "coming from level N" special case mentioned above in 2). But right now that has not been implemented.

4. Single user mode

Switching to single user mode is done by switching to runlevel 1. That will cause all services to be stopped (assuming they all have a K script in /etc/rc1.d). The runlevel 1 scripts will then switch to runlevel "S" which usually has no scripts - all it does is spawn a shell directly on /dev/console for maintenance.

5. Halt/reboot

Going to runlevel 0 or 6 will cause the system to be halted or rebooted, respectively. For example, if we go to runlevel 6 (reboot) first all /etc/rc6.d/KXXxxxx scripts will be executed alphabetically with "stop" as the first argument.

Then the /etc/rc6.d/SXXxxxx scripts will be executed alphabetically with "stop" as the first argument as well. The reason is that there is nothing to start anymore at this point - all scripts that are run are meant to bring the system down.

In the future, the /etc/rc6.d/SXXxxxx scripts MIGHT be moved to /etc/rc6.d/K1XXxxxx for clarity.

 

How does BUM work?

 

Boot-Up Manager first scans all of your boot-related directories. They are:

Analyzing scripts and symlinks, BUM will show you which of them are activated and which script is present on your system but not activated at boot time. When you change activation check box for a script, and click on the Save button, BUM will perform several actions, depending on a range of factors.

The list of "active" services is parsed thru a gate and only valid services are displayed as active. To be a valid active service, the symlinks should meet these requirements:

- Either S or K symlink in each of rc[1-5].d
- K symlink in each of rc[06].d (only in default mode)

 
  1. Activate a de-activated script. When a service is activated, all symlinks in RL 2-3-4-5 are changed to
    Sxx, where xx is:

    1 - a saved number, if BUM has recorded one, or
    2 - the S sequence number in runlevels 2-5 if there is one, or
    3 - 20 if installed by update-rc.d run with "defaults" option, or
    4 - 100 minus the K sequence number in runlevel 2

  2. Deactivate an activated script. When an active service is deactivated, all symlinks in RL 2-3-4-5 are
    changed to Kxx, where xx is:

    1 - the value of Kxx in RL 1. If none
    2 - the value of Kxx in RL 0. If none
    3 - 100 minus the value in RL 2

    If it is a script installed with "deafults" option in postinst, it will always have a priority=20. The symlinks in RL 0-1-6 are not changed.
 

 

Runlevel S scripts

These are those scripts linked in /etc/rcS.d directory. For these services, BUM will not allow editing to the user.

These scripts are very critical for the system. BUM will not allow any change on rcS.d scripts.

 

Each action performed through BUM, will be logged into /var/log/syslog.

 

How to Use BUM

BUM can be started from the menu entry (which launches gksudo bum), or from a terminal. If launched from a terminal, you should use 'sudo bum' from the user, or just 'bum' from root.

Note: first time you run BUM, it will require some more time to create its disk cache. Please be patient for a moment...

BUM has three main tabbed-views: Summary, Services, Startup and shutdown scripts . To get access to views other then the Summary view, you should check the Advanced box in the lower left part of the main window. The Summary view is aimed to give to the general user an overview of services activated and de-activated at boot, ordered by startup sequence, with a short description-title for each service. If you want to activate/deactivate some of them, just click on the check box. When you are finished, press on the "Apply changes" button. You will have the chance to apply your modifications (scripts will be stopped or started) or let them be applied at next boot of your system.

In the last column of this view (Running) you will see a list of icons. These are their meanings:

the script has generated a service daemon, which is currently running.
the script has an associated service daemon, which is currently NOT running.
the script is a "one-shot" type. It provides initial settings at boot and does not run a service daemon.
BUM is not able to detect if the script is running a daemon.

 

Almost all the services started with init scripts in runlevels 2-3-4-5 and rcS.d don't have a standard, "human readable" description of their main behaviour. Very often the package description for these services is very cryptic and the common user is quite disorientated and doesn't understand the meaning. Boot-Up Manager (BUM) will use a special list to display the package description in its main view window.

If in the "Running" column of BUM main window list you have displayed a question mark (?) it means that BUM doesn't have a nicer description for the service and so it is showing the apt-cache description. The internal "human-text" list is under a constant updating process. To contribute to this list, please feel free to update this wiki-web page.

In the Services view you have a detailed description in the lower pane window (this information is taken from package cache), while in the upper pane, all the scripts are listed together with Start/Stop priority in each runlevel, ordered by startup sequence.

Close to the "Run level" header, you will find an asterisk which mark the current default runlevel.

By right-clicking on the list, a useful context-driven menu will be opened. You can then activate/deactivate the script on-the-fly, stop or start the relevant service, or change the script startup priority, depending on which tabbed-view are you on at the moment.