Linux Solutions

Welcome to the tutorial guide. The tutorial will provide guidance and instructions about the system startup and shutdown and also the bootscripts and how to manage the scripts. Annvix uses “init” to startup and shutdown. The “init” system is a hybrid system which is based on Gentoo’s init system. Annvix uses runit to manage things.

Please note that Linux system uses SysVinit, which is based on the SysV scheme and is made up of a set of scripts that setup the system, mount filesystems, and in turn call a number of other scripts which are known as initscripts that start services. These initscripts can be called independently to start and stop individual services. At system shutdown, these scripts shutdown all running services, unmount filesystems, and then halt or reboot the system.

Annvix, using runit, starts and stops services with run scripts, rather than initscripts. Initscripts are still used for one-time services and non-daemon services, such as setting up the firewall, calling kudzu to detect hardware, starting the network, etc. The SysV init scheme calls for the use of “runlevels”. When the Linux kernel boots, it mounts the root filesystem and then typically executes a script called rc.sysinit which sets up the basic system configuration and usually checks the filesystems. It then calls a script called rc with an argument; this argument is the runlevel to execute. Different Linux distributions may use a variation of the following, but this is by-and-large a typical runlevel scheme:
• 0: complete machine stop
• 1: single-user mode
• 2: multi-user mode
• 3: multi-user mode, with networking
• 4: unused
• 5: similar to runlevel 3, but starts the graphical login interface, for use with X
• 6: restart

Annvix does not use numbered runlevels, but it uses named runlevels which allow for much more customisation, although it shouldn’t really be necessary to change the defaults. Please note that Annvix comes with the following named runlevels:

• default: multi-user mode, with networking
• single: multi-user mode, without networking and no services starting (other than cron, mingetty, and socklog)

When the bootloader executes the kernel to load, it also uncompresses a ramdisk image, which contains modules to load in order to mount the root filesystem and a script called linuxrc which creates some temporary partitions, mounts required filesystems, and so forth. Once this script is done, and the root filesystem is mounted, it executes /sbin/init, which is provided by the runit package. init is the first process of any Linux system, and with runit, if init is the first process, it replaces itself with /sbin/runit(8) which then executes the script /etc/runit/1 to start “stage 1″. Runit operates in three stages:
• 1: one-time startup tasks
• 2: the normal operating system; if this stage exits abnormally it will be restarted
• 3: halt/reboot

One stage 1 is started by executing /etc/runit/1, that script then executes /sbin/rc with a single argument: 1. This argument tells rc that the system is starting; an argument of 0 would tell rc that the system is shutting down. The rc script does all the heavy lifting of mounting other filesystems, performing filesystem checks, loading kernel modules to interact with different hardware devices, and so forth. The rc script also calls the traditional “initscripts” found in the runlevel’s definition directory: /etc/runlevels/default for the “default” runlevel. When rc exits and control is passed back to the stage 1 script, stage 1 completes and stage 2 begins.

Stage 2, which is executed by /etc/runit/2, starts the supervised services found in the runlevel’s service directory: /etc/runlevels/default/service for the “default” runlevel. Each runlevel has it’s own service directory; the rc script sets /service as a symlink to the runlevels service directory at boot.
Stage 3 is called when a superuser calls the halt(8), reboot(8), or shutdown(8) commands. This will exit stage 2 and call /etc/runit/3, which signals runit to shutdown all supervised services and then calls the rc script with the single argument ‘0′.

Managing Initscripts with rc-update
Traditional Linux distributions will use programs like service to start/stop and otherwise manage services (Annvix uses srv(8)), and chkconfig to add or remove services from a particular runlevel. Annvix does not use chkconfig because chkconfig is very much tied to number-based runlevels. Instead, Annvix uses a modified version of Gentoo’s rc-update script.
If a user wants to see what initscripts are called for each runlevel, then he/she can look in /etc/runlevels/[runlevel] or use rc-update:
# rc-update -s
apparmor | default
iptables | default
keytable | default
kheader | default
kudzu | default
netfs | default
network | default
rc.local | default single

This will show a user that the initscript /etc/init.d/rc.local is called in both runlevels “default” and “single” and the rest of the supplied initscripts are executed only in the “default” runlevel.
If a user wants to add an initscript to a runlevel, then he/she can use the “add” command, which is provided below:

# rc-update add iptables single
iptables added to runlevel single

After a user runs this command, it will add the /etc/init.d/iptables initscript to the “single” runlevel. A user can also view this by looking in /etc/runlevels/single/:
# ls -al /etc/runlevels/single/
total 4
drwxr-x— 3 root admin 54 Mar 5 23:47 .
drwxr-xr-x 4 root root 33 Mar 30 2007 ..
lrwxrwxrwx 1 root root 20 Mar 5 23:43 03iptables -> /etc/init.d/iptables
lrwxrwxrwx 1 root root 20 Mar 5 23:47 99rc.local -> /etc/init.d/rc.local
drwxr-x— 2 root admin 4096 Dec 29 21:32 service

If a user wants to remove an initscript from some runlevel, then he/she can use the “del” command which is provided below:

# rc-update del iptables single
‘iptables’ removed from the following runlevels: single

Looking at the runlevel directory, a user will note the symlink with a numbered prefix. This is similar to SysVinit, Annvix uses this to order which scripts are executed. If a user views the SysV system then he/she will be able to view following:
$ ls -l /etc/rc.d/rc3.d/
total 0
lrwxrwxrwx 1 root root 20 Jan 2 2007 K66messagebus -> ../init.d/messagebus*
lrwxrwxrwx 1 root root 19 Jan 2 2007 K68rpcidmapd -> ../init.d/rpcidmapd*
lrwxrwxrwx 1 root root 17 Jan 2 2007 K69rpcgssd -> ../init.d/rpcgssd*
lrwxrwxrwx 1 root root 20 Jan 2 2007 K69rpcsvcgssd -> ../init.d/rpcsvcgssd*
lrwxrwxrwx 1 root root 16 Jan 2 2007 K72autofs -> ../init.d/autofs*
lrwxrwxrwx 1 root root 19 Jan 2 2007 K95harddrake -> ../init.d/harddrake*
lrwxrwxrwx 1 root root 18 Jan 2 2007 S03iptables -> ../init.d/iptables*
lrwxrwxrwx 1 root root 14 Jan 2 2007 S04acpi -> ../init.d/acpi*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S10network -> ../init.d/network*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S11portmap -> ../init.d/portmap*
lrwxrwxrwx 1 root root 16 Jan 2 2007 S12syslog -> ../init.d/syslog*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S13partmon -> ../init.d/partmon*
lrwxrwxrwx 1 root root 15 Jan 2 2007 S14acpid -> ../init.d/acpid*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S14nfslock -> ../init.d/nfslock*
lrwxrwxrwx 1 root root 15 Jan 2 2007 S25netfs -> ../init.d/netfs*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S29numlock -> ../init.d/numlock*
lrwxrwxrwx 1 root root 14 Sep 12 23:01 S30nscd -> ../init.d/nscd*
lrwxrwxrwx 1 root root 13 Jan 2 2007 S40atd -> ../init.d/atd*
lrwxrwxrwx 1 root root 16 Jan 2 2007 S40smartd -> ../init.d/smartd*
lrwxrwxrwx 1 root root 14 Dec 19 10:45 S55sshd -> ../init.d/sshd*
lrwxrwxrwx 1 root root 14 Jan 2 2007 S56ntpd -> ../init.d/ntpd*
lrwxrwxrwx 1 root root 20 Jan 2 2007 S56rawdevices -> ../init.d/rawdevices*
lrwxrwxrwx 1 root root 13 Jan 2 2007 S60nfs -> ../init.d/nfs*
lrwxrwxrwx 1 root root 18 Jan 2 2007 S75keytable -> ../init.d/keytable*
lrwxrwxrwx 1 root root 17 Mar 10 2007 S80postfix -> ../init.d/postfix*
lrwxrwxrwx 1 root root 17 Sep 6 18:25 S85proftpd -> ../init.d/proftpd*
lrwxrwxrwx 1 root root 15 Jan 2 2007 S90crond -> ../init.d/crond*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S95kheader -> ../init.d/kheader*
lrwxrwxrwx 1 root root 11 Jan 2 2007 S99local -> ../rc.local*

A user will notice that each script can have a different prefix; for example, the S prefix is for Start and the K prefix is for Kill — in relation to the service. In this way, services are ordered in how the start and stop. Annvix only concerns itself with how services are started, and calls stop for the initscripts in alphabetical order. Because Annvix does not handle or support changing runlevels “on the fly” there is no need to be concerned with ordered stops, so Annvix does not use a lettered/numeric prefix as other Linux distributions.

One thing to note is that if the special “stop” initscript exists, it will be executed before any other initscripts are called. This script is called /etc/init.d/rc.local-stop, and is a counterpart to /etc/init.d/rc.local which is only executed on start (and never executed on stop). Therefore, if a user wants to start something in rc.local and wants to ensure a clean shutdown, then he/she can use rc.local-stop to stop it or do whatever cleanup is required.

Package Management
Annvix uses the RPM package management system to handle binary packages, and also uses RPM packages as the resulting package format for the ports system. RPM is a robust packaging format, and with good frontends such as apt and urpmi, the stigma attached to RPM packages is largely moot.

If you followed the tutorial guide then you would have learnt about the the system startup and shutdown for Annvix.