% Unix/Linux Boot Process, GRUB, Run Levels, services, telinit, chkconfig % Ian! D. Allen - idallen@idallen.ca - www.idallen.com % Winter 2013 - January to April 2013 - Updated Wed May 8 21:01:24 EDT 2013 Topics and Readings =================== Fedora Textbooks ---------------- - In *A Practical Guide to Fedora and Red Hat Enterprise Linux*, 5th ed., by Mark Sobell, Prentice Hall, ISBN 0-13-706088-2 - Chapter 11 (pages 417 – 424, 430-1, 435) - Chapter 15 (pages 543, 551) - Boot Process - Boot Loaders: Specifically GRUB - see also the LInux LOader: `lilo` - Run Levels: display, change, etc. - Startup Files The Internet ------------ - Wikipedia: [Booting] - We are using [GRUB Legacy] - For the latest GRUB\< see [GRUB Reference] - [GRUB Legacy Tutorial] - [GRUB Legacy Manual] Definitions: boot and boot loader ================================= - To **boot** or **bootstrap**: load an operating system kernel into memory and start it running - A **boot loader**: a small program used in the bootstrap process - Usually resides on the starting sector(s) of a hard disk called the Boot Sector or the Master Boot Record (**MBR**) - Responsible for locating a secondary boot loader or the actual O/S kernel What happens at power on ======================== - The firmware Basic Input/Outpus System (**BIOS**) program in the firmware executes first - BIOS is stored in some form of persistent firmware that keeps its information even when the power is off - The BIOS usually performs a Power On System Test (**POST**) - checks memory, itemizes disks, etc. - After the POST, the BIOS searches for “bootable media” - some disk partitions can be marked “bootable” - bootable media store boot information in the MBR - If a valid MBR is found, the BIOS uses or executes it to find an O/S - MBR may contain actual code that passes control to a secondary boot record stored inside a partition - partition boot record may then locate the system kernel and load it The Linux `/boot` directory =========================== - Linux usually keeps its kernels under directory `/boot`, which may be a separately mounted partition at the start of the disk - Usually `/boot` is located near the beginning of the disk because older BIOSes can’t address disk blocks at the middle or end of larger disks! - Once Linux is running, Linux has no problem addressing the whole disk. - The `/boot` problem is a BIOS limitation, not a Linux limitation. - Modern BIOSes can find and boot an O/S anywhere on the disk. - You may need a “GPT” UEFI MBR, not an MS-DOS MBR, for disks larger than 2TB - the old MS-DOS partition table can’t describe disks much over 2TB The Grand Unified Boot Loader - `GRUB` ====================================== - Replacement for the older LInux LOader (**LILO**) boot loader. - More flexible than LILO; more options; easier to configure and update - We are using the [GRUB Legacy Version 0.9x][GRUB Legacy] in this course - Still used by Enterprise systems (long maintenance cycles) - Modern desktop Linux systems (since about 2007) are using the more complex [GRUB 2 (version 1.xx)][GRUB Reference] - Note that GRUB legacy (the first version of GRUB) is number 0.9x - Note that the second version of GRUB is number 1.xx - GRUB allows loading of any free operating system directly - Recognizes many types of file systems and kernel executable formats - Allows chain loading (loading another boot loader) of proprietary operating systems (e.g. Windows) - Automatic boot can be configured using a text file named (depending on the version) `menu.lst`, `grub.conf`, or `grub.cfg` under `/boot/grub/` - Modern versions of GRUB (versions 1.xx) create this file from pieces stored under `/etc/grub.d/` and you should edit the pieces, not the main file - Some systems create a symlink from `/etc/grub.conf` to the real location under `/boot/grub/` - On other systems (e.g. SuSE), `/etc/grub.conf` has a completely different function - to configure GRUB installation! - GRUB configuration files are installed and then maintained by system updates - Fedora’s [Anaconda] installer sets up and installs GRUB for you; other distributions do the same - You don’t have much to do unless you need to add a special boot entry - GRUB can also be run in interactive command mode, where you type GRUB commands directly into GRUB to find and load operating systems - Note that GRUB ** completion is **broken** when GRUB is used at the command line in Fedora 12 - it works fine when GRUB is booted stand-alone. A sample GRUB Legacy configuration file (version 0.9x) ------------------------------------------------------ All versions of GRUB use a configuration file under `/boot/grub` to display a menu of alternative operating systems to boot. Without a configuration file, GRUB starts in interactive mode and you have to specify and type everything yourself. With a configuration file, you can select from a menu list of choices. In GRUB Legacy, each choice in the configuration file starts with a `title` keyword followed by a descriptive name: # Sample GRUB menu.lst or grub.conf file (GRUB Legacy version 0.9x) timeout=30 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu default=0 # this sdb disk has partition sdb1 for /boot and sdb2 for / (ROOT) # (Note how pathnames do *not* start with /boot on a separate partition!) title Fedora 2.6.31 on second disk root (hd1,0) kernel /vmlinuz-2.6.31.5-127.fc12.i686.PAE ro root=/dev/sdb2 initrd /initramfs-2.6.31.5-127.fc12.i686.PAE.img # this sdc disk has partition sdc1 for / (ROOT) and uses a /boot directory # (not a separate /boot partition, so pathnames must start with /boot) title Old Fedora 2.6.23 on third disk password sesame root (hd2,0) kernel /boot/vmlinuz-2.6.23.15.137.fc8 ro root=/dev/sdc1 initrd /boot/initrd-2.6.23.15.137.fc8.img # this first disk partition has a Windows boot loader in the first sector title Windows on first disk rootnoverify (hd0,0) makeactive chainloader +1 Notes: - The part of the file before the first `title` section is for general GRUB configuration options - see below for the keywords: - `timeout`: how long the menu waits before selecting the default - `default`: which `title` section to boot when the time-out happens - counts from zero – the first **boot menu entry** is number zero! - `splashimage`: a pretty picture to put behind the GRUB menu - `hiddenmenu`: hide the GRUB menu during the boot process - The `title` **boot menu entry** sections for Linux kernels have these keywords: - `root`: lets you set this prefix for all following GRUB pathnames, similar to `cd` in the shell - this is *not* the Linux ROOT; this is the GRUB ROOT and uses GRUB device names such as `(hd0,0)` - this is prepended to all incomplete pathname references, e.g. incomplete `/foo` becomes complete path `(hd1,0)/foo` - `kernel`: the Linux kernel image followed by optional kernel options - `initrd`: the initial RAM disk to be used by the kernel at boot time - `password`: require the given password to boot this menu entry - Windows may not be able to boot if it isn’t the first partition of the first disk! See the GRUB documentation for ways to work around this. We don’t handle Windows bugs in this course. - **Do not move or remove the GRUB configuration files!** GRUB expects the files to be in a particular location on disk, and moving them may cause GRUB to fail to find them, requiring a re-install of GRUB. - you can edit the files **in-place** as long as you do not delete or move them `grub.conf` keywords -------------------- - Global options (used *before* any `title` sections): - `default` n (optional): The nth `title` boot menu item, starting at 0, will be booted. Otherwise, the first (zeroth) `title` item is booted. - `timeout` 20 (optional): Number of seconds before booting into default. - `password` sesame (optional): Disable interactive editing and protect all boot menus that include the `lock` option - Individual menu options (used *within* the `title` sections): - `title`: Menu title of this boot menu - `kernel`: Location of Linux kernel file, followed by options - `lock` (optional): Requires global password to boot this menu entry - `password` (optional): require the given password to boot this menu entry Note: To find out about additional GRUB commands, type `help` at the GRUB shell prompt, and see the above Resources. GRUB Device and file Naming Convention - `(hd0,0)/grub/menu.lst` ---------------------------------------------------------------- A full GRUB path name specification is a device name (often a partition name) followed by a file system pathname inside that partition (relative to the start of the partition), e.g. `(hd0,0)/grub/menu.lst` where `/grub/menu.lst` is relative to the *start of the partition* `(hd0,0)`. (This is similar to DOS/Windows and its drive letters.) - Device names are identified by enclosing parentheses `()` - Hard disks are named `hd`, e.g `(hd0)`, `(hd1)` - Floppy disks are named `fd`, e.g. `(fd0)`, `(fd1)` - Disks and Floppies are numbered sequentially, starting at 0 (ZERO!) - Partition numbers are given after commas, e.g. `(hd0,0)`, `(hd0,1)` - Partitions are also numbered sequentially, starting at 0 (ZERO!) - WARNING! Linux numbers disks starting at `a`! GRUB starts at ZERO. - WARNING! Linux numbers partitions starting at 1 (ONE)! GRUB starts at ZERO. - Linux `sda1` is GRUB `(hd0,0)`; Linux `sdc2` is GRUB `(hd2,1)` - Examples: - `(hd0)` – First recognized hard disk (any type: SCSI, ATA, USB, etc.); usually corresponds to `/dev/sda` - `(fd0)` – First recognized floppy diskette; usually corresponds to `/dev/fd0` - `(hd0,0)` – First partition on first recognized hard disk; usually corresponds to `/dev/sda1` - `(hd1,4)` – First *logical* drive on second recognized hard disk; usually corresponds to `/dev/sdb5` - The GRUB `root` command can pre-set the device name for all following pathnames - e.g. “`root (hd0,2)`” followed by “`kernel /linux`” is the same as “`kernel (hd0,2)/linux`” Effect of separate `/boot` partition on GRUB pathnames ------------------------------------------------------ GRUB configuration files are stored under directory `/boot/grub` in Linux. `/boot/grub` is the Linux pathname, not necessarily the GRUB pathname, because GRUB pathnames are composed of a partition name followed by a pathname inside the partition, e.g. `(hd0,0)/some/path/name` where `/some/path/name` is relative to the *start of the partition*. Since partitions are mounted on directories in Linux, and those directory pathnames prefix the names inside the partition for Linux pathnames, a GRUB pathname and a Linux absolute pathname will always differ, except for the one partition that is mounted on ROOT (because prefixing an absolute pathname with `/` (ROOT) doesn’t change it). ### `/boot` is on the ROOT partition If `/boot` is not its own partition, then it is a directory inside the existing ROOT partition. GRUB shell command pathnames referring to the kernel and to GRUB configuration files will also be inside the ROOT partition and will therefore all start with the ROOT partition name followed by the subdirectory name `/boot` inside the partition, e.g. `(hd0,0)/boot/grub/grub.conf` refers to the Linux pathname `/boot/grub/grub.conf` because `/boot` is an ordinary directory inside the ROOT partition `(hd0,0)`. ### `/boot` is its own partition If `/boot` is its own mounted partition, then the GRUB files will be on this separate BOOT partition (not on the ROOT partition) that gets mounted on `/boot` and the GRUB pathnames (which are relative to the start of the partition, not relative to the ROOT of the file system) will therefore *not* start with `/boot`, they will start directly under the BOOT partition device name e.g. `(hd0,0)/grub/grub.conf` refers to the Linux pathname `/boot/grub/grub.conf` (because `(hd0,0)` is mounted on `/boot` and so `/boot` is prefixed to the part of the pathname contained inside the partition). ### Summary of GRUB pathnames - Separate `/boot` partition: `(hd0,0)/grub/grub.conf` - `/boot` is under ROOT: `(hd0,0)/boot/grub/grub.conf` Fedora 12 uses a separate BOOT partition. The comments in its GRUB configuration file tell you this. Do not use `/boot` at the start of GRUB pathnames because the pathnames are inside their own BOOT partition (that will be mounted on `/boot`) and GRUB addresses pathnames by partition name. Installing GRUB --------------- Your Linux installation already installed GRUB for you. If you have to re-install GRUB, you may find (or be able to install) the `grub-install` script that will do it for you. You can also try it manually, if the GRUB setup files are already stored under `/boot/grub`: - As `root`, type `grub` at the command line: this will load GRUB and display the GRUB shell prompt `grub>` - Type `setup` with two GRUB pathname arguments: the boot sector installation device and the device containing the GRUB setup files - the GRUB setup files (e.g. grub.conf) must be on the given partition - To put GRUB into the MBR of the first disk:   `setup (hd0) (hd0,0)` - Exit GRUB with the `quit` command when done Most versions of the GRUB shell have TAB command completion, where you can type part of a device or pathname and GRUB will give you all the possible completions. The command-line GRUB in Fedora 12 is broken, and does not have this feature. The GRUB that runs at boot time is not broken and does have the TAB completion feature. BE CAREFUL. GRUB does not ask you for confirmation! If you type the wrong thing, you will overwrite your boot sector with garbage and be unable to boot your system. You will need to boot a “live” CD and repair. Booting without a GRUB menu - interactive GRUB commands ------------------------------------------------------- If `grub.conf` is not present or has been moved, GRUB cannot display a menu. In this case it will display the GRUB interactive shell, similar to what you get by typing `grub` at a Linux command line. The interactive GRUB shell has its own prompt (`grub>`) and its own built-in commands, some with the same names as BASH shell commands. Be clear on when you are typing into the GRUB shell and when you are typing into BASH. The same command name may do different things, depending on whether GRUB executes it or BASH executes it. Most versions of the GRUB shell have TAB command completion, where you can type part of a device or pathname and GRUB will give you all the possible completions. The command-line GRUB in Fedora 12 is broken, and does not have this feature enabled. The GRUB that runs stand-alone at boot time is not broken and does have the TAB completion feature. Type `help` for a partial list of commands you can use. Some examples: - `cat` - display a text file - `geometry` - display information about disk partitions - `find` - find which device (partition) contains a pathname - `md5crypt` - prompt for and encrypt a password At the GRUB shell prompt, GRUB commands can be entered to query the system, see text files, and load and then boot a kernel image. Examples: grub> find /grub/grub.conf grub> cat (hd0,0)/grub/grub.conf grub> kernel (hd0,0)/vmlinuz ro root=/dev/sda2 grub> initrd (hd0,0)/initrd grub> boot Note: The GRUB shell can also be accessed by following directions (usually by pressing the letter `c`) when the GRUB menu is presented. `[Esc]` brings you from the GRUB shell back to the menu. Pressing `e` allows you to edit boot menu entries of grub.conf. Pressing `b` boots the edited menu item. Some versions of GRUB allow typing `a` to go directly to a GRUB `kernel` line and edit the options. Kernel options: single user mode, other Run Levels, kernel panic ================================================================ Options provided on the `kernel` line in a GRUB configuration file influence how the system boots and what software might be enabled. The options are given after the kernel image name on a `kernel` line and allow you to boot your system with different features enabled. Some versions of GRUB allow you to type `a` while viewing the GRUB menu, to go directly to a GRUB `kernel` line and edit the kernel options. Options are separated by blanks, e.g.: `ro single txt 3` When you edit these GRUB lines, you are only changing the in-memory copy of the configuration, you are *not* changing the actual configuration in the GRUB configuration file on disk. To make any edit permanent, you must boot the system (single-user is fine) and actually edit the GRUB configuration file and save it. Booting Single User Mode (Maintenance Mode) ------------------------------------------- Single-user mode is a “half-up” state used for system repair and maintenance (especially for resetting the `root` password!). The system only brings up a minimal number of services (often none). The GUI is not started. Networking may not be enabled. Not all disks may be mounted. The console terminal gets a shell running as the `root` user. To boot into single-user mode, add the word `single` as an option to a `kernel` line in a GRUB boot menu entry and then boot that entry, e.g.: kernel (hd0,0)/vmlinuz ro root=/dev/sda3 single Booting into a different Run Level ---------------------------------- (Run Levels are summarized below.) To start Linux with a different Run Level than the default, add the Run Level digit to the end of the `kernel` options line during boot, e.g. to boot Run Level 3 (which on Fedora 12 means boot multi-user without the X11 GUI window system), use the GRUB menu to add `3` to the end of the `kernel` options: kernel /vmlinuz ro root=/dev/sda2 3 Fixing a kernel panic (missing ROOT file system) ------------------------------------------------ If you moved your ROOT file system to a different partition but forgot to change the GRUB configuration file, your kernel will “panic” and tell you it can’t find the ROOT file system. You can reboot into the GRUB shell and edit the `root=` option on the `kernel` line to point to the correct ROOT partition: kernel (hd0,0)/vmlinuz ro root=/dev/sdb2 - [FoxTrot Kernel Panic] Legacy Run Levels and Services ============================== The System V **Run Levels** system was a crude way to specify groups of services (such as the Apache Web Server, or the Secure Shell Server) that were to be started and stopped together. Run Levels expect that a system boots into a fixed state, with a fixed set of disks and fixed set of services. They do not work well with systems where devices come and go after booting, e.g. dynamic USB drives, printers, cameras, hotplug disks, etc. Since Enterprise Servers (systems with a long maintenance window) typically boot into a fixed state where devices don’t come and go, Run Levels are still a useful and simple way of configuring Enterprise systems. Enterprise systems still use Run Levels, and even the newer versions of the system boot process (using the new **Upstart** or **Systemd**) emulate traditional Run Levels. (Fedora 12 uses **Upstart** to emulate Run Levels.) The system can be in only one Run Level at a time, but can be moved to any other Run Level. Changing Run Levels cause services to be started and stopped to match what is supposed to be available in that Run Level. Each Run Level is given a number. The broad meaning of each Run Level is usually documented in comments inside the file `/etc/inittab` in a table that looks similar to this (from Fedora 12): # 0 - Halt (Do NOT set the initdefault default run level to this) # 1 - Single user mode # 2 - Multi-user, without NFS (The same as 3, if you do not have networking) # 3 - Full multi-user mode, text-only # 4 - not used # 5 - Full multi-user mode, with X11 # 6 - reboot (Do NOT set the initdefault default run level to this) id:5:initdefault: The last line of this file (`initdefault`) is the only active (non-comment) line in the file. It gives the Run Level number that the system will normally boot into. As you can see above, Fedora 12 Linux uses seven Run Levels, numbered `0` through `6`, with Run Level `5` being the default Run Level. You can tell the system to change Run Levels using commands such as `telinit`. The `shutdown` and `reboot` commands also change Run Levels. Changing Run Levels will cause some system services to stop and others to start. Run Levels are not an ordered sequence; the system goes *directly* between Run Levels, it does not “pass through” Run Levels 3 and 4 when going from, say, Run Level 2 to Run Level 5. The meanings of the Fedora 12 Run Levels are given in the `/etc/inittab` file: 0. **Halt** - Immediately stop all services and power off the system without any warning to the logged-in users. (Use the `shutdown` command instead!) - Do **not** set the default Run Level `initdefault` to this or else you will never be able to boot your system! 1. **Single user** mode - Stop all (or almost all) services but do *not* power off the system. - Put up a single `root` shell on the system console (no password needed). - Remote logins are not allowed since no SSH service is running. - Used for system maintenance and resetting a forgotten `root` password. 2. **Limited Multiuser** mode - Enables most system services, but no graphical GUI or X11 services. - The system consoles show a text-only `login:` prompt. - Does not enable the Networking File System (**NFS**) service. - The same as Run Level 3, if you do not have networking. 3. **Full multiuser** mode - Enables most system services, but no graphical GUI or X11 services. - The system consoles show a text-only `login:` prompt. 4. unused 5. **full multiuser with X11 GUI** - Enables all configured system services. - Full multiuser mode with the X11 GUI (graphical) window system. 6. **Reboot** - Immediately stop all services and reboot the system without any warning to the logged-in users. (Use the `shutdown` command instead!) - Do **not** set the default Run Level `initdefault` to this or else you will never be able to boot your system! (Use the `shutdown` command instead!) Higher numbered Run Levels generally mean more and more services started, but the highest Run Level (`6`) is used to reboot the system without warning. Run Levels are not an ordered sequence. When going from, say, Run Level 2 to Run Level 5 the system goes *directly* between Run Levels; it does not “pass through” Run Levels 3 and 4. > Fedora 12 actually uses the newer Upstart event-based services system, but > hides most of that Upstart functionality behind a traditional Run Levels > emulation layer. You can read about Upstart below. Default Run Level in `/etc/inittab` ----------------------------------- - The default Run Level to use at boot time is set by the `initdefault` option of the `/etc/inittab` file. It looks like this if your default Run Level is number `5`: id:5:initdefault: Display Run Level ----------------- To display previous and current system Run Levels, use the `runlevel` command: $ runlevel N 5 An `N` will be printed as the previous Run Level right after booting, otherwise the first number will be the previous run level number. Change Run Level ---------------- Only `root` can tell the system to change Run Levels. To change Run Levels (as `root`) use the `telinit` command with an argument of the desired Run Level, e.g. `telinit 5` See the table of Run Levels in the comments in the `/etc/inittab` file to know what each Run Level number means. You rarely need to explicitly tell the system to change Run Levels. The `shutdown` command is much better for shutting down and/or rebooting the system, because `shutdown` will send a warning message to all logged-in users. - You can change Run Levels while the system is running using commands such as `telinit`, but that command doesn’t print any warning messages. - Usually use `shutdown` to shut down or reboot the system, because `shutdown` will send a warning message to all logged-in users. Displaying and Controlling Run Level Services with `chkconfig` -------------------------------------------------------------- System services are started and stopped for each Run Level. You can see which services are on and off in each of the seven Run Levels using the `chkconfig` command: $ chkconfig | wc 57 456 3195 # there are 57 possible services available $ chkconfig --list sshd sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off $ chkconfig | grep syslog rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off $ chkconfig NetworkManager 0:off 1:off 2:on 3:on 4:on 5:on 6:off abrtd 0:off 1:off 2:off 3:on 4:off 5:on 6:off acpid 0:off 1:off 2:on 3:on 4:on 5:on 6:off atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off avahi-daemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off bluetooth 0:off 1:off 2:off 3:on 4:on 5:on 6:off btseed 0:off 1:off 2:off 3:off 4:off 5:off 6:off bttrack 0:off 1:off 2:off 3:off 4:off 5:off 6:off cpuspeed 0:off 1:on 2:on 3:on 4:on 5:on 6:off ... many more lines ... The `chkconfig` output gives a list of the known services and whether each service is supposed to be turned on or off in that Run Level. The `chkconfig` command cannot tell you if the service is *actually* and *currently* on or off; it only knows what *should* be on or off and it does not start or stop any services itself. If you want to check whether or not a service is actually running, use the `ps` command to look for it. You can use shell pipelines on the output of `chkconfig`, for example to find out which services are enabled to start in at least one Run Level: # chkconfig | grep ':on' NetworkManager 0:off 1:off 2:on 3:on 4:on 5:on 6:off abrtd 0:off 1:off 2:off 3:on 4:off 5:on 6:off acpid 0:off 1:off 2:on 3:on 4:on 5:on 6:off atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off avahi-daemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off bluetooth 0:off 1:off 2:off 3:on 4:off 5:off 6:off cpuspeed 0:off 1:on 2:on 3:on 4:on 5:on 6:off crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off cups 0:off 1:off 2:on 3:on 4:on 5:on 6:off ... many more lines ... A common use of `chkconfig` is to change which services are supposed to be turned on or off in which Run Level (requires `root` permissions): # chkconfig --list bluetooth bluetooth 0:off 1:off 2:off 3:on 4:on 5:on 6:off # chkconfig --level 45 bluetooth off # chkconfig --list bluetooth bluetooth 0:off 1:off 2:off 3:on 4:off 5:off 6:off You can also completely remove (delete) a service from `chkconfig` so that it does not appear at all in the output. (RTFM) Displaying and Controlling Run Level Services without `chkconfig` ----------------------------------------------------------------- If `chkconfig` is not available, you can still discover and change which services run in each Run Level by knowing how the System V Run Levels system works. Services (such as the SSH server or the HTTP server) are started using shell scripts. All the SysV-style service start-up scripts are kept in directory `/etc/init.d/`: $ ls /etc/init.d/http* /etc/init.d/ssh* /etc/init.d/httpd /etc/init.d/sshd $ wc /etc/init.d/http* /etc/init.d/ssh* 119 426 3158 /etc/init.d/httpd 234 669 4537 /etc/init.d/sshd Symbolic links to these scripts are placed in directory `/etc/rc?.d/`, e.g. the services for Run Level 3 are listed under directory `/etc/rc3.d`: $ ls -l /etc/rc3.d/*ssh* /etc/rc3.d/*http* lrwxrwxrwx. 1 root root 15 2011-09-02 09:53 /etc/rc3.d/K15httpd -> ../init.d/httpd lrwxrwxrwx. 1 root root 14 2011-09-02 09:54 /etc/rc3.d/S55sshd -> ../init.d/sshd The symbolic links starting with `S` and a number start a service; the symbolic links starting with `K` and a number stop (“kill”) a service, e.g. /etc/rc3.d/K15httpd # symlink to kill the HTTP daemon in Run Level 3 /etc/rc3.d/S55sshd # symlink to start the SSH daemon in Run Level 3 Each of those symlinks points to a script file responsible for killing or starting the indicated service. Without `chkconfig`, you can change what services get killed or started by manually adding or removing symlinks from the corresponding `/etc/rc?.d` Run Level directories. A service is started in a Run Level by calling its SysV start-up script with a single argument of `start`. A service is stopped in a Run Level by calling its SysV start-up script with a single argument of `stop`. Most Run Level changes that cause these scripts to run happen at boot time and system shut down, though you can use the `telinit` command to change Run Levels if you need to. While is is always possible to create and remove the symbolic links in the `rc?.d` directories by hand (using `ln -s` and `rm`), the `chkconfig` command is the preferred tool for listing and manipulating these symbolic links in their Run Level directories. Resetting symlinks for a service -------------------------------- Many/most of the SysV start-up scripts in `/etc/init.d` contain a `chkconfig` comment line in the comments at the start of the script. The comment line might look something like this: $ grep 'chkconfig' /etc/init.d/crond # chkconfig: 2345 90 60 The above shell comment line is readable by `chkconfig` if you give `chkconfig` the `reset` option for that service. With `reset`, `chkconfig` will read the above line and make sure there are start/stop symlinks for the service in Run Levels 2,3,4,5 at priority 90 and 60. For example: # chkconfig crond reset Now `chkconfig --list crond` will show `crond` enabled in Run Levels 2,3,4,5. The `crond` service will start at priority 90 and stop at priority 60. You can confirm this by looking for the symlinks in all the `/etc/rc?.d` directories: $ chkconfig --list crond crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off $ ls /etc/rc?.d/*crond* /etc/rc0.d/K60crond /etc/rc3.d/S90crond /etc/rc6.d/K60crond /etc/rc1.d/K60crond /etc/rc4.d/S90crond /etc/rc2.d/S90crond /etc/rc5.d/S90crond Note: You can always add the appropriate start/stop symlinks manually in the `rc?.d` directories if the above procedure isn’t possible because the `chkconfig` command is missing. Don’t depend on `chkconfig`! Starting and Stopping Services using `service` ---------------------------------------------- Using `chkconfig` to change which servers are *supposed* to be on or off in any Run Level does not change what services are *actually* and *currently* running (or not running). A service may have died unexpectedly, or have been stopped or started manually. System services can be started, stopped, and reset using the `service` command (as `root`) with a service name and an appropriate command operation argument: # service crond Usage: /etc/init.d/crond {start|stop|status|restart|condrestart|try-restart|reload|force-reload} # service crond status crond (pid 1597) is running... # service crond restart Stopping crond: [ OK ] Starting crond: [ OK ] # service crond status crond (pid 8207) is running... All services support the `start` and `stop` commands, which are used to start and stop services when the system changes Run Levels. You can omit any commands to generate a list of what other commands are possible: # service httpd Usage: httpd {start|stop|restart|condrestart|reload|status|fullstatus|graceful|help|configtest} If your system is missing the `service` command, you can always execute any service script directly from the `/etc/init.d/` directory, passing it an argument of what function you want to perform: # /etc/init.d/crond status crond (pid 8207) is running... Remember: `chkconfig` only specifies what services *should* be on or off in a Run Level. It does not start or stop any services. You can start or stop any services in any Run Level using the `service` command. The Future: Upstart and/or Systemd ================================== - Wikipedia **Upstart**: - Wikipedia **Systemd**: Fixed Run Levels do not work well on dynamic systems such as user Desktop or Workstation systems where devices come and go after booting, e.g. USB drives, printers, cameras, hotplug disks, etc. Run Levels can only start a fixed set of services, and there is no clean way using Run Levels to start a new service when a new device is plugged in and to stop it when the device is unplugged. Modern Unix/Linux systems moved away from static Run Levels to use the more dynamic and complex **Upstart** system of starting/stopping services. Run Levels are “emulated” by **Upstart**, but **Upstart** can handle devices coming and going dynamically much better. When devices were added/removed, “events” were generated that could start and stop related system services. Red Hat replaced the legacy System V init system (Run Levels) with the improved [Upstart] system for their [Enterprise Linux 6]. The complexity and limitations of **Upstart** prompted Lennart Poettering to write a new Linux-only **Systemd** session manager. Fedora 15 then moved from using **Upstart** to use the new Linux-only **Systemd**. Red Hat Enterprise Linux is planning to move from **Upstart** to **Systemd** in the next release. (Yes, **Upstart** was used for only *one* release.) The Debian Linux distribution is reluctant to use a Linux-only start-up system that won’t work on non-Linux systems (such as Debian GNU/kFreeBSD), and so Debian and Ubuntu still use the **Upstart** system, not **Systemd**. - A comparison, written by the author of Systemd, of System V init (Run Levels), Upstart, and [Systemd] - Lennart’s original article describing the motivation for getting rid of Upstart and replacing it with [Systemd][1] - Fedora explains **Systemd**: - Jonathan Corbet’s comments on [Systemd][2] - **Systemd** cheat sheet: Unclear Future for Upstart and/or Systemd ----------------------------------------- In early 2013, there is still considerable controversy on the move from booting with **Upstart** to booting with **Systemd**. Fedora and Red Hat are moving to **Systemd**; Debian and Ubuntu are staying with **Upstart**; other distributions are watching the battle to see who wins. See these references for some background on the heated discussions: - **Systemd** controversy causes a [fork of UDEV] - *Gentoo developers could also potentially be joined by Debian developers in what could turn out to be a groundswell of protest against the Red Hat led developments in **Systemd**.* - A developer complains that [**Systemd** is breaking promises] - *We are now being told that, contrary to what was said when udev was migrated into the systemd tree, running udev without systemd is now deprecated and untested and might go away completely. How surprising, nobody ever predicted that when it migrated in, oh wait yes we did, and were assured that we were wrong, that standalone udev would always be supported for those of us who weren’t using systemd. Way to destroy your userbase’s trust in you…* - Linus Torvald rants [against the `udev` developers] - *Stop this crazy. FIX UDEV ALREADY, DAMMIT. […] “Two-faced lying weasel” would be the most polite thing I could say. But it almost certainly will involve a lot of cursing.* - Linus Torvald rants [against the **Systemd** developers] - *I also call bullshit on your “it will surely be fixed when we know what’s the right fix” excuses. […] Kay, you are so full of sh*t that it’s not funny. You’re refusing to acknowledge your bugs, you refuse to fix them even when a patch is sent to you, and then you make excuses for the fact that we have to work around *your* bugs, and say that we should have done so from the very beginning.* Good luck with the future of Linux booting. -- | Ian! D. Allen - idallen@idallen.ca - Ottawa, Ontario, Canada | Home Page: http://idallen.com/ Contact Improv: http://contactimprov.ca/ | College professor (Free/Libre GNU+Linux) at: http://teaching.idallen.com/ | Defend digital freedom: http://eff.org/ and have fun: http://fools.ca/ [Plain Text] - plain text version of this page in [Pandoc Markdown] format [Booting]: http://wikipedia.org/wiki/Booting [GRUB Legacy]: http://www.gnu.org/software/grub/grub-legacy.html [GRUB Reference]: http://www.gnu.org/software/grub/ [GRUB Legacy Tutorial]: http://www.dedoimedo.com/computers/grub.html [GRUB Legacy Manual]: http://www.gnu.org/software/grub/manual/legacy/grub.html [Anaconda]: https://fedoraproject.org/wiki/Anaconda [FoxTrot Kernel Panic]: http://www.gocomics.com/foxtrot/2006/11/09 [Upstart]: http://pearlin.info/?p=552 [Enterprise Linux 6]: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html [Systemd]: http://0pointer.de/blog/projects/why.html [1]: http://0pointer.de/blog/projects/systemd.html [2]: http://lwn.net/Articles/389149/ [fork of UDEV]: http://www.linuxplanet.com/news/linux-top-3-gentoo-forks-udev-peppermint-respins-and-linux-3.7-rc7.html [**Systemd** is breaking promises]: https://lkml.org/lkml/2012/10/3/618 [against the `udev` developers]: https://lkml.org/lkml/2012/10/2/303 [against the **Systemd** developers]: https://lkml.org/lkml/2012/10/3/484 [Plain Text]: 750_booting_and_grub.txt [Pandoc Markdown]: http://johnmacfarlane.net/pandoc/