Suse Runlevels and RC Scripts

In SuSE, environment variables that will be used by startup scripts are set in /etc/rc.config. If some subsystems need very fancy configuration, config files are put in /etc/rc.config.d. The


rc.confg

file may set parameters (IPADDR_0=192.168.1.101, ROOT_LOGIN_REMOTE="no") or specify options about whether or not to start (START_ROUTED="no").

YaST (Yet another Setup Tool) is a GUI tool for maintaining the contents of /etc/rc.config. In most Unix systems providing GUI administration interfaces, the actual data maintained by the GUI is stored in a file that is amenable to text editing as well. If you use a GUI administration tool such as YAST, you should also look at the files that the tool maintains. This helps you understand the details of the underlying model better.

The message "Uncompressing Linux..." signals that the kernel taking control of your hardware. It checks and sets your console -- more precisely: the BIOS registers of graphics cards and output format -- to read BIOS settings and to initialize basic hardware interfaces. Next, your drivers ``probe'' existing hardware and initialize it accordingly. After checking the partitions and mounting the root file system, the kernel starts init, which ``boots'' (Unix jargon) the main system with all its programs and configurations. The kernel controls the entire system, including hardware access and the CPU time programs use.

The program init is the process responsible for initializing the system itself in the required way. All other processes are considered child processes of init. It is started directly by the kernel and resists signal 9, which normally kills processes. All other programs are either started directly by init or by one of its ``child'' processes.

init is centrally configured via the /etc/inittab file. Ther's were runlevels aredefined. It also specifies which services and daemons are available in each of the levels. Depending on the entries in /etc/inittab, several scripts are run by init. All these scripts reside in the directory /etc/init.d.

The entire process of starting the system and shutting it down is maintained by init. From this point of view, the kernel can be considered a background process whose task it is to support all other processes, which are making Unix API called, as well as to adjust CPU time and hardware access according to requests from other programs.

In Linux, runlevels define how the system is started. After booting, the system starts as defined in /etc/inittab in the line initdefault. Usually this is 3 or 5. An alternative to this is assigning a special runlevel at boot time (e.g. , at the boot prompt). The kernel passes any parameters it does not need directly to init.

To change runlevels while the system is running, enter init and the corresponding number as an argument. Only the system administrator is allowed to do this.

init 1 (or shutdown now) causes the system to change to single user mode, which is used for system maintenance and administration. After finishing his work, the administrator can switch back to the normal runlevel by entering init 3, which starts all the essential programs and allows regular users to log in and to work with the system. On the other hand, init 0 (or shutdown -h now) causes the system to halt. init 6 (or shutdown -r now) causes it to shut down with a subsequent reboot.

You should not use runlevel 2 if your system mounts the /usr partition via NFS. The /usr directory holds important programs essential for the proper functioning of the system. Because the NFS service is not made available by runlevel 2 (local multiuser mode without remote network), the system would be seriously restricted in many aspects.

Runlevel 5 is the default runlevel in all SuSE Linux standard installations. Users are prompted for login directly under a graphical interface.

If you have already installed and configured the X Window System properly as described in 5) and want users to log in via a graphical user interface, change the runlevel to 5. Try it first by typing init 5 to see whether the system works as expected. If it does, use YaST to set the default runlevel to 5.

If /etc/inittab is damaged, the system might not boot properly. Therefore, be extremely careful while editing /etc/inittab and always keep a backup of an intact version. To repair damage, try entering init=/bin/sh after the kernel name at the boot prompt to boot directly into a shell. After that, replace /etc/inittab with your backup version using the cp command.

Generally, two things happen when you change runlevels. First, stop scripts of the current runlevel are launched, closing down some programs essential for the current runlevel. Then start scripts of the new runlevel are started. Here, in most cases, a number of programs will be started.

When changing into the same runlevel as the current runlevel, init only checks /etc/inittab for changes and starts the appropriate steps (e.g. , for starting a getty on another interface).

Init Scripts

All scripts are located in /etc/init.d. Scripts for changing the runlevel are also found there, but are called via symbolic links from one of the subdirectories (/etc/init.d/rc0.d to /etc/init.d/rc6.d). This is just for clarity reasons and avoids duplicate scripts (e.g. , if they are used in several runlevels). Because every script can be executed as both a start and a stop script, these scripts must understand the parameters ``start'' and ``stop''. The scripts understand, in addition, the ``restart'', ``reload'', ``force-reload'', and ``status'' options.

Links in each runlevel-specific subdirectory make it possible to associate scripts with different runlevels. When installing or uninstalling packages, such links are added and removed with the help of the program insserv (or using /usr/lib/lsb/install_initd, which is a script calling this program). See [8]insserv for details.

Below is a short introduction to the boot and stop scripts launched first (or last, respectively) as well as an explanation of the maintaining script.

Adding init Scripts

You can create your own scripts and easily integrate them into the scheme described above. For instructions about the formatting, naming, and organization of your custom scripts, refer to the specifications of the LSB and to the man pages of init, init.d, and insserv. Additionally consult the man pages of startproc and killproc.

Faulty init scripts may freeze your machine. Edit such scripts with great care and, if possible, subject them to heavy testing in the multiuser environment.

On the other hand, if a script already present in /etc/init.d/ should be integrated into the existing runlevel scheme, create the links in the runlevel directories right away, either with insserv or by enabling the corresponding service in the runlevel editor of YaST. Your changes are applied during the next reboot -- the new service will be started automatically.

The YaST Runlevel Editor

After starting this YaST module, it displays overview listing all the available services and the current status of each service -- whether they are enabled or not. With the radio buttons, decide whether to use the module in ` Simple Mode' or in ` Expert Mode'. The default ` Simple Mode' should be sufficient for most purposes. The leftmost column shows the name of the service, the center column indicates its current status, and the right-hand column gives a short description. For the selected service, a more detailed description is provided in the lower part of the window. To enable a service, select it in the tabl then select ` Enable'. The same steps apply to disable a service.

For detailed control over the runlevels in which a service is started or stopped or to change the default runlevel, first select ` Expert Mode'. This mode displays the current default runlevel or ``initdefault'', which means the runlevel into which the system boots by default. Normally, the default runlevel of a SuSE Linux system is runlevel 5 (full multiuser mode with network and XDM). A suitable alternative might be runlevel 3 (full multiuser mode with network).

This YaST dialog allows selection of one of the runlevels (as listed in Table 12.1) as the new default. Additionally use the table in this window to enable or disable individual services and daemons. The table lists the services and daemons available, tells whether they are currently enabled on your system, and, if so, for which runlevels. After selecting one of the rows with the mouse, click the check boxes representing the runlevels (` B', ` 0', ` 1', ` 2', ` 3', ` 5', ` 6', and ` S') to define the runlevels where the selected service or daemon should be running. Runlevel 4 is always undefined to allow for the creation of a custom runlevel. Finally, a brief description of the currently selected service or daemon is provided just below the table overview.

With ` Start' and ` Stop', decide whether a server should be implemented. Check the current status is checked via ` Update', if this has not already been done automatically. ` Reset to Default Value' restores the settings to their default state. ` Activate Service' only appears if the service is currently disabled. ` Finish' saves the system configuration.

Faulty runlevel settings may render a system unusable. Before applying your changes, make absolutely sure you know about their consequences.

SuSEconfig and /etc/sysconfig

The main configuration of SuSE Linux can be done via the configuration files in /etc/sysconfig. Former versions of SuSE Linux relied on /etc/rc.config for system configuration, but it became obsolete in previous versions. /etc/rc.config will not be created at installation time, as all system configuration is controlled via /etc/sysconfig. However, if /etc/rc.config exists at the time of a system update, it will remain intact.

The individual files in /etc/sysconfig are only read by the scripts to which they are relevant. This ensures that network settings, for instance, need to be parsed only by network-related scripts. Apart from that, there are many other system configuration files that are generated according to the settings in /etc/sysconfig. This task is performed by SuSEconfig. For example, if you change the network configuration, SuSEconfig is likely to make changes to the file /etc/host.conf as well, as this is one of the files relevant for the network configuration.

If you change anything in these files manually, run /sbin/SuSEconfig afterwards to make sure all the necessary changes are made in all the relevant places. If you change the configuration using the YaST sysconfig editor, all changes are applied automatically -- YaST automatically starts SuSEconfig to update the configuration files as needed.

This concept enables you to make basic changes to your configuration without needing to reboot the system. BEcause some changes are rather complex, some programs must be restarted for the changes to take effect. For instance, changes to the network configuration may require a restart of the network programs concerned. This can be achieved by entering the commands rcnetwork stop and rcnetwork start.

The recommended way to change the system configuration includes the following steps:

This procedure is mainly relevant if you have changed system-wide settings (such as network configuration). It is not necessary to go into single user mode for small changes, but it ensures all relevant programs are correctly restarted.

To disable the automatic configuration of SuSEconfig, set the variable <ENABLE_SUSECONFIG> in /etc/sysconfig/suseconfig to no. Do not disable SuSEconfig if you want to use the SuSE installation support. It is also possible to disable the autoconfiguration partially.

The YaST sysconfig Editor

The files where the most important SuSE Linux settings are stored are located in the /etc/sysconfig directory. The sysconfig editor presents the settings options in an easy-to-read manner. The values can be modified and subsequently added to the individual configuration files in this directory. In general, it is not necessary to edit them manually, however, because these files are automatically adjusted when installing a package or configuring a service.

[Modifications of /etc/sysconfig/ files] Do not modify the /etc/sysconfig files if you lack previous experience and knowledge. It could do considerable damage to your system. The files in /etc/sysconfig include a short comment for each variable to explain what effect they actually have.

The YaST sysconfig dialog is split into three parts. The left part of the dialog window shows a tree view of all configurable variables. As soon as you have selected a variable, the right part displays both the current selection and the current setting of this variable. Below, a third window displays a short description of the variable's purpose, possible values, the default value, and the actual configuration file from which this variable originates. The dialog also provides information about which configuration script is executed after changing the variable and which new service is started as a result of the change. YaST asks you to confirm your changes and informs you which scripts will be executed after leaving the dialog by selecting ` Finish'. Also select the services and scripts to skip for now, so they are started later

Old News ;-)

Runlevel - Wikipedia, the free encyclopedia

An introduction to services, runlevels, and rc.d scripts By Mark Alexander Bain

January 11, 2006 | Linux.com

What's the first thing that you do once you've logged onto Linux? Is it to manually start up a processes such as Apache or MySQL, or even start your network connection? Or do you have to stop applications that have started up without your telling them to, and which are overloading your machine? If you have unwanted processes starting at boot time, or find yourself starting necessary services manually, let's make your life a little bit easier by introducing you the world of Linux services.
A Linux service is an application (or set of applications) that runs in the background waiting to be used, or carrying out essential tasks. I've already mentioned a couple of typical ones (Apache and MySQL). You will generally be unaware of services until you need them.
How can you tell what services are running, and more importantly, how can you set up your own?

System V vs. BSD

In this article I'm dealing with System V (derived from AT&T System V) based distributions. This is the most common Linux init system. Another is based on BSD (Berkeley Software Distribution). What's the difference between the two? Basically BSD doesn't have any runlevels. This means that System V gives a lot more flexibility to a system administrator.

Most Linux distros put startup scripts in the rc subdirectories (rc1.d, rc2.d, etc.), whereas BSD systems house the system scripts in /etc/rc.d. Slackware's init setup is similar to BSD systems, though Slackware does have runlevels and has had System V compatibility since Slackware 7.

Let's start by looking at how the system is set up, and in particular at the directory /etc/rc.d. Here you will find either a set of files named rc.0, rc.1, rc.2, rc.3, rc.4, rc.5, and rc.6, or a set of directories named rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, and rc6.d. You will also find a file named /etc/inittab. The system uses these files (and/or directories) to control the services to be started.
If you look in the file /etc/inittab you will see something like:
id:4:initdefault:

l0:0:wait:/etc/rc.d/rc.0
l6:6:wait:/etc/rc.d/rc.6
x1:4:wait:/etc/rc.d/rc.4
The boot process uses these parameters to identify the default runlevel and the files that will be used by that runlevel. In this example, runlevel 4 is the default and the scripts that define runlevel 4 can be found in /etc/rc.d/rc.4.

And what is a runlevel? You might assume that this refers to different levels that the system goes through during a boot up. Instead, think of the runlevel as the point at which the system is entered. Runlevel 1 is the most basic configuration (simple single user access using an text interface), while runlevel 5 is the most advanced (multi-user, networking, and a GUI front end). Runlevels 0 and 6 are used for halting and rebooting the system.

There are, however, differences between Linux distributions. For instance, Fedora uses runlevel 5 for X-based logins, whereas Slackware uses runlevel 4 to do the same job. Therefore, you should check your documentation before making any changes. This table shows a generic list of configurations (and some examples of different distros) taken from Linux - The Complete Reference (R.Peterson, Osbourne/McGraw-Hill).

Run Level Generic Fedora Core Slackware Debian

0 Halt Halt Halt Halt

1 Single-user mode Single-user mode Single-user mode Single-user mode

2 Basic multi-user mode (without networking) User definable (Unused) User definable - configured the same as runlevel 3 Multi-user mode

3 Full (text based) multi-user mode Multi-user mode Multi-user mode - default Slackware runlevel

4 Not used Not used X11 with KDM/GDM/XDM (session managers) Multi-user mode

5 Full (GUI based) multi-user mode Full multi-user mode (with an X-based login screen) - default runlevel User definable - configured the same as runlevel 3 Multi-user mode

6 Reboot Reboot Reboot Reboot

As you can see there are slight (but important) differences between Linux distributions. One thing is common between them -- if you want to change the default level, you must edit /etc/initab. You will need to be root or use sudo to edit this file, naturally.

Why would you want to change the runlevel? Normally you will only use full GUI or text multi-user mode -- runlevels 4 or 5. You'd only want runlevels 1 or 2 if you have some system problems and you want the most basic access. Runlevels 0 and 6 should never be used as a default (for obvious reasons -- you don't want the system to shutdown or reboot as soon as you turn it on). You can, of course, change mode whilst the system is running. Type init followed by the required runlevel e.g.:
init 6
This will reboot the system.

The boot process, or to be more accurate the init command, will decide the runlevel to select (in the example above it's 4) and from that will decide the rc.d script files to be run. In this case either the file /etc/rc.d/rc.4 or any files in the directory /etc/rc.d/rc4.d. Let's look at an example rc.d script file. Here's the default rc.4 file for Slackware 10.2:
# Try to use GNOME's gdm session manager:
if [ -x /usr/bin/gdm ]; then
  exec /usr/bin/gdm -nodaemon
fi

# Not there?  OK, try to use KDE's KDM session manager:
if [ -x /opt/kde/bin/kdm ]; then
  exec /opt/kde/bin/kdm -nodaemon
fi

# If all you have is XDM, I guess it will have to do:
if [ -x /usr/X11R6/bin/xdm ]; then
  exec /usr/X11R6/bin/xdm -nodaemon
fi
A quick guide to the boot process

When you boot your computer, the first thing that it will do is load the bootloader -- either GRUB or LILO in most cases. The bootloader will then load the Linux kernel -- the core operating system. Next, a process called init starts. This process reads the file /etc/inittab to establish the runlevel to use. The runlevel is the start mode for the computer.

Once init knows the runlevel it will look for the appropriate files or directories as defined in /etc/initab.

Init will then either run the script files defined by /etc/initab, or run the script files in the directories defined by /etc/initab (depending on the set up of your system).

Finally, init will present you with the logon mode that you've selected.

As you would expect, since runlevel 4 is the Slackware X11 mode, the commands are all concerned with the setting up of the graphical interface.
In the other distros (such as Fedora and Debian) you'll find that the scripts to be run are actually symbolic links to files in the directory /etc/init.d -- the central repository for all startup scripts. So all you have to do is to write your startup script, place it in /etc/init.d, and then create a symbolic link to it from the appropriate runlevel directory (or runlevel file, if that's what your system uses).

For example, runlevel 2 is the default runlevel for Debian in non-GUI mode. If you're running Apache 2 on Debian, you'd find an init script for Apache 2 under /etc/init.d called apache2. A symlink, S91apache2, points to /etc/init.d/apache2 from /etc/rc2.d -- this tells init to start Apache 2 in runlevel 2, but only after other services with lower S numbers.

When the system is shut down, there is another symlink in the /etc/rc0.d and /etc/rc6.d directories (halt and reboot, respectively) that starts with a K instead of an S, which tells init to shut down the process.

If this all still sounds a bit too complicated, you can instead simply make use of the /etc/rc.d/rc.local file. This script file is run once, before all other scripts have run but before the logon prompt appears. By default it looks something like:
#!/bin/bash
#
# /etc/rc.local - run once at boot time
# Put any local setup commands in here:
You can append your instructions onto the end of the file by defining another script to be run:
/root/bin/start_bb
Or you can modify rc.local by adding the commands themselves:
modprobe -r uhci
modprobe usb-uhci
eciadsl-start
iptable -F
iptables -A INPUT -i ppp0 -p tcp --syb -j DROP
netdate time.nist.gov
Here a USB modem is initialized, a connection set up to a broadband network, some basic security is set up, and then the local time is synchronized with a time server. You can also start Apache or MySQL:
apachectl start
echo "/usr/bin/mysqld_safe &" | su mysql
Note that some distros, such as Debian, do not use rc.local for startup scripts. See the Debian FAQ if you'd like to add startup scripts for Debian or Debian-derived distros.

One final thought -- in addition to startup scripts (for rc.local), try to remember to write close-down scripts to be added to rc.0 and rc.6. This ensures that your services are shut down neatly and not left in strange states when the system halts.

About shutting down -- how do you stop a service from starting when you reboot? It's just the reverse of what we've already looked at. Either edit the relevant runlevel file (comment the lines out rather than removing them) or remove the link from the runlevel directory. Note that it may not be necessary to do this manually, as many distros include tools to manage services. For example, Red Hat and Fedora use chkconfig, while Debian uses update-rc.d.

From this brief discussion, I hope you can see how useful rc.d scripts can be when it comes to controlling the services to be run on your PC. You can now add your own as required, as well as look at existing ones that you may not require and which are slowing down your logon or overloading your PC.

News	Recommended Books	Recommended Links	Installation Checklist	YaST	RPM	Packages
Init.d scripts	Xinetd				Humor	Etc