|< Day Day Up >|
There are a lot of ways to start and stop a Linux system. Plus, there are initialization scripts for controlling how various services start up, and there are different system runlevels, each of which can run a different set of services. Run this command:
$ ps axfl
Take a look at the top, at process number 1 (this is slimmed-down; yours will show more columns and lines):
UID PID PPID STAT TTY TIME COMMAND 0 1 0 S ? 0:03 init
But why doesn't ps afxl show init as the root of the process tree? The ppids tell the story:
UID PID PPID STAT TTY TIME COMMAND 0 1 0 S ? 0:03 init 0 2 1 SW ? 0:00 [keventd] 0 0 1 SWN ? 0:00 [ksoftirqd_CPU0] 0 0 1 SW ? 0:00 [kswapd] 0 10 1 SW ? 0:00 [kreiserfsd] 0 101 1 SW ? 0:00 [kapmd] 1 274 1 S ? 0:00 /sbin/portmap 0 360 1 S ? 0:00 /sbin/syslogd 0 376 1 S ? 0:00 /usr/sbin/slapd 0 387 376 S ? 0:00 \_ /usr/sbin/slapd 0 388 387 S ? 0:00 \_ /usr/sbin/slapd 0 389 1 S ? 0:00 /usr/sbin/cupsd
On Red Hat and Debian systems, the /etc/rc*.d directories do not contain the actual startup scripts, but rather symlinks to scripts in /etc/init.d. By linking to a master script directory, /etc/init.d, unnecessary duplication is avoided. And, in a master stroke of sheer ingenuity, the way the symlinks are named determines how the services will run. For example, consider:
$ ls -go S20cupsys lrwxrwxrwx 1 16 Sep 9 17:51 S20cupsys -> ../init.d/cupsys
S20 means the service cupsys is to be started with a priority level of 20. Lower numbers equal higher priority. If it were K20cupsys, that would mean the service is to be killed. (The Linux world is harsh.) This is a simple way to ensure that services are stopped and started the way you want, and in the right order.
There may be even more variations in other distributions, and theoretically runlevels 7-9 exist, though they are not used. It's easy enough to see what each runlevel does—simply read the rc*.d directories.
|< Day Day Up >|