Difference between revisions of "SysVinit"

From ArchWiki
Jump to: navigation, search
(urge users to migrate to systemd (part 2))
(Considerations before switching: netcfg is discontinued)
 
(34 intermediate revisions by 9 users not shown)
Line 1: Line 1:
 
[[Category:Boot process]]
 
[[Category:Boot process]]
 
[[Category:Daemons and system services]]
 
[[Category:Daemons and system services]]
[[Category:System recovery]]
 
 
[[el:Init and inittab]]
 
[[el:Init and inittab]]
 
[[es:SysVinit]]
 
[[es:SysVinit]]
 
[[it:SysVinit]]
 
[[it:SysVinit]]
 +
[[ja:SysVinit]]
 
[[zh-CN:SysVinit]]
 
[[zh-CN:SysVinit]]
{{Warning|SysVinit is obsoleted in Arch Linux [https://www.archlinux.org/news/end-of-initscripts-support/] and has been dropped from the [[official repositories]]. You need to upgrade to [[systemd]].}}
+
{{Related articles start}}
 +
{{Related|init}}
 +
{{Related articles end}}
 +
{{Style|Blog-like writing, duplicate information}}
 +
{{Out of date|Needs to be checked against {{AUR|initscripts-fork}}}}
 +
{{Warning|SysVinit is not officially supported in Arch Linux [https://www.archlinux.org/news/end-of-initscripts-support/].}}
  
On systems based on SysVinit, '''init''' is the first process that is executed once the Linux kernel loads. The default init program used by the kernel is {{ic|/sbin/init}} provided by {{Pkg|systemd-sysvcompat}} (by default on new installs, see [[systemd]]) or {{Aur|sysvinit}}. The word '''init''' will always refer to sysvinit in this article.
+
On systems based on SysVinit, '''init''' is the first process that is executed once the Linux kernel loads. The default init program used by the kernel is {{ic|/sbin/init}} provided by {{Pkg|systemd-sysvcompat}} (by default on new installs, see [[systemd]]) or {{AUR|sysvinit}}. The word '''init''' will always refer to sysvinit in this article.
  
 
'''inittab''' is the startup configuration file for init located in {{ic|/etc}}. It contains directions for init on what programs and scripts to run when entering a specific runlevel.
 
'''inittab''' is the startup configuration file for init located in {{ic|/etc}}. It contains directions for init on what programs and scripts to run when entering a specific runlevel.
Line 14: Line 19:
 
Although a SysVinit-based Arch system does use init, most of the work is delegated to the [[#Main Boot Scripts]]. This article concentrates on init and inittab.
 
Although a SysVinit-based Arch system does use init, most of the work is delegated to the [[#Main Boot Scripts]]. This article concentrates on init and inittab.
  
==Overview of init and inittab==
+
== Installation ==
 +
 
 +
Install {{AUR|sysvinit}} {{AUR|initscripts-fork}} from the [[AUR]]. This step will remove {{Pkg|systemd-sysvcompat}}, and you will use sysvinit on reboot. To restore [[systemd]], append {{ic|1=init=/usr/lib/systemd/systemd}} to the [[kernel command line]].
 +
 
 +
Additional init scripts are available at [https://bitbucket.org/TZ86/arch-rcscripts/src/3e83aeed6c68c6252b8db1428c10a717bc9e05ff/community/?at=master arch-rcscripts]. See [[Init#Configuration]] for generic configuration steps.
 +
 
 +
== Overview of init and inittab ==
  
 
init is always process 1 and, other than managing some swap space, is the parent process to '''all''' other processes. You can get an idea of where init lies in the process hierarchy of your system with {{ic|pstree}}:
 
init is always process 1 and, other than managing some swap space, is the parent process to '''all''' other processes. You can get an idea of where init lies in the process hierarchy of your system with {{ic|pstree}}:
Line 43: Line 54:
 
See also {{ic|man 5 inittab}} and {{ic|man 8 init}}.
 
See also {{ic|man 5 inittab}} and {{ic|man 8 init}}.
  
==Installation==
+
== Switching runlevel ==
{{Expansion|This section should explain how to replace [[systemd]] with {{AUR|sysvinit}}.}}
+
  
==Switching runlevel==
+
=== Through bootloader ===
  
===Through bootloader===
+
To change the runlevel the system boots into, simply add the desired runlevel {{ic|n}} to the respective bootloader's configuration line. A common application of this is [[Start X at login#inittab]]. To boot to the desired runlevel, add its number to the [[kernel parameters]] (e.g. {{ic|3}} for runlevel 3).
To change the runlevel the system boots into, simply add the desired runlevel {{ic|n}} to the respective bootloader's configuration line. A common application of this is [[Start X at Login#inittab]]. To boot to the desired runlevel, add its number to the [[kernel parameters]] (e.g. {{ic|3}} for runlevel 3).
+
  
 
The run-level was appended to the end so the kernel knows what run-level to start with. To use another init program (e.g. [[systemd]]), add {{ic|1=init=/bin/systemd}} or similar.  
 
The run-level was appended to the end so the kernel knows what run-level to start with. To use another init program (e.g. [[systemd]]), add {{ic|1=init=/bin/systemd}} or similar.  
Line 55: Line 64:
 
{{Note|If using some init other than sysvinit, the runlevel parameter might be ignored.}}
 
{{Note|If using some init other than sysvinit, the runlevel parameter might be ignored.}}
  
===After boot up===
+
=== After boot up ===
 +
 
 
After the system has booted up, you may issue {{ic|telinit n}} to inform init to change the runlevel to {{ic|n}}. init then reads inittab and "diffs" runlevel n and current runlevel - killing processes not present in the new runlevel and carrying out actions not present in the old runlevel. Processes present in both runlevels are left untouched. The killing procedure is actually a little complex; again, technical details can be found in the init manpage.
 
After the system has booted up, you may issue {{ic|telinit n}} to inform init to change the runlevel to {{ic|n}}. init then reads inittab and "diffs" runlevel n and current runlevel - killing processes not present in the new runlevel and carrying out actions not present in the old runlevel. Processes present in both runlevels are left untouched. The killing procedure is actually a little complex; again, technical details can be found in the init manpage.
  
 
init doesn't watch inittab. You need to call {{ic|telinit}} explicitly to apply modifications to inittab. The command {{ic|telinit q}} causes init to re-examine inittab but not switch runlevel.
 
init doesn't watch inittab. You need to call {{ic|telinit}} explicitly to apply modifications to inittab. The command {{ic|telinit q}} causes init to re-examine inittab but not switch runlevel.
  
==inittab==
+
== inittab ==
 +
 
 
In this section we examine common entries in inittab, in the same order as they appear in the default inittab used by Arch. After that there are a few examples to help you create your own inittab entry.
 
In this section we examine common entries in inittab, in the same order as they appear in the default inittab used by Arch. After that there are a few examples to help you create your own inittab entry.
  
 
{{Warning|Always test a modified {{ic|/etc/inittab}} with {{ic|telinit q}} before you reboot, or a small syntax error can prevent your system from booting.}}
 
{{Warning|Always test a modified {{ic|/etc/inittab}} with {{ic|telinit q}} before you reboot, or a small syntax error can prevent your system from booting.}}
  
===Default Runlevel===
+
=== Default Runlevel ===
 +
 
 
The default runlevel is 3. Uncomment or add this if you prefer to boot into runlevel 5 (which is used for X conventionally) by default:
 
The default runlevel is 3. Uncomment or add this if you prefer to boot into runlevel 5 (which is used for X conventionally) by default:
  
Line 72: Line 84:
 
}}
 
}}
  
===Main Boot Scripts===
+
=== Main Boot Scripts ===
 +
 
 
These are the main Arch init scripts.
 
These are the main Arch init scripts.
  
Line 82: Line 95:
 
}}
 
}}
  
===Single User Boot===
+
=== Single User Boot ===
 +
 
 
Sometimes your kernel may fail to boot up all the way, due to a corrupted or dead hard drive or filesystem, missing key files, etc. In that case your init image may automatically enter into '''single-user mode''' which only allows root login and uses {{ic|/sbin/sulogin}} instead of {{ic|/sbin/login}} to control the login process. You can also boot into single-user mode by appending the letter {{ic|S}} to your kernel command line in your [[GRUB]], [[LILO]], or [[syslinux]] configuration. If you would like something other than sulogin to run, specify it here.
 
Sometimes your kernel may fail to boot up all the way, due to a corrupted or dead hard drive or filesystem, missing key files, etc. In that case your init image may automatically enter into '''single-user mode''' which only allows root login and uses {{ic|/sbin/sulogin}} instead of {{ic|/sbin/login}} to control the login process. You can also boot into single-user mode by appending the letter {{ic|S}} to your kernel command line in your [[GRUB]], [[LILO]], or [[syslinux]] configuration. If you would like something other than sulogin to run, specify it here.
 
{{bc|
 
{{bc|
Line 88: Line 102:
 
}}
 
}}
  
===Gettys and Login===
+
=== Gettys and Login ===
 +
 
 
These are crucial entries that run the [[getty]]s on your terminals. Most default configurations will have several gettys running on ttys1-6 which is what pops up on your screen with the login prompt. Also see openvt, chvt, stty, and ioctl.
 
These are crucial entries that run the [[getty]]s on your terminals. Most default configurations will have several gettys running on ttys1-6 which is what pops up on your screen with the login prompt. Also see openvt, chvt, stty, and ioctl.
 
{{bc|
 
{{bc|
Line 95: Line 110:
 
}}
 
}}
  
===Ctrl+Alt+Del===
+
=== Ctrl+Alt+Del ===
When the special key sequence {{Keypress|Ctrl+Alt+Del}} is pressed, this determines what to do.
+
 
 +
When the special key sequence {{ic|Ctrl+Alt+Del}} is pressed, this determines what to do.
 
{{bc|
 
{{bc|
 
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
 
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
 
}}
 
}}
  
===X Programs===
+
=== X Programs ===
 +
 
 
If you are not afraid to debug, you can figure out how to start all sorts of programs from inittab. One useful type of program is to start your login manager when the runlevel is 5, multi-user-x-mode. In the following example you can see how to start [[SLiM]] when entering runlevel 5.
 
If you are not afraid to debug, you can figure out how to start all sorts of programs from inittab. One useful type of program is to start your login manager when the runlevel is 5, multi-user-x-mode. In the following example you can see how to start [[SLiM]] when entering runlevel 5.
 
{{bc|
 
{{bc|
Line 108: Line 125:
 
}}
 
}}
  
===Power-Sensing Scripts===
+
=== Power-Sensing Scripts ===
 +
 
 
Init can communicate with your UPS device and execute processes based on the status of the UPS. Here are some examples:
 
Init can communicate with your UPS device and execute processes based on the status of the UPS. Here are some examples:
 
{{bc|
 
{{bc|
Line 115: Line 133:
 
}}
 
}}
  
===Custom Keyboard Request===
+
=== Custom Keyboard Request ===
The following line adds a custom function for when a special key sequence is pressed. You can modify this special key sequence to be anything you like, similar to a {{Keypress|Ctrl+Alt+Del}}.
+
 
 +
The following line adds a custom function for when a special key sequence is pressed. You can modify this special key sequence to be anything you like, similar to a {{ic|Ctrl+Alt+Del}}.
 
{{bc|
 
{{bc|
 
kb::kbrequest:/usr/bin/wall "Keyboard Request -- edit /etc/inittab to customize"
 
kb::kbrequest:/usr/bin/wall "Keyboard Request -- edit /etc/inittab to customize"
 
}}
 
}}
  
====Trigger the kbrequest====
+
==== Trigger the kbrequest ====
 +
 
 
You can trigger the special key sequence '''kbrequest''' by sending the WINCH signal to the init process (1) as root (via sudo). In this example, the command:
 
You can trigger the special key sequence '''kbrequest''' by sending the WINCH signal to the init process (1) as root (via sudo). In this example, the command:
 +
 
  kill -WINCH 1
 
  kill -WINCH 1
 +
 
Causes {{ic|wall}} to write to all ttys:
 
Causes {{ic|wall}} to write to all ttys:
 
{{bc|
 
{{bc|
Line 130: Line 152:
 
}}
 
}}
  
==See Also==
+
== Writing rc.d scripts ==
*[[Automatic login to virtual console]]
+
 
*[[Disable Clearing of Boot Messages]]
+
Initscripts uses rc.d scripts to used to control the starting, stopping and restarting of [[daemons]].
*[[Start X at Login]]
+
 
*[[xinitrc]]
+
=== Guideline ===
*[[Display Manager]]
+
 
*[[SLiM]]
+
* Source {{ic|/etc/rc.conf}}, {{ic|/etc/rc.d/functions}}, and optionally {{ic|/etc/conf.d/DAEMON_NAME}}.
 +
* Arguments and other daemon options should be placed in {{ic|/etc/conf.d/DAEMON_NAME}}. This is done to separate configuration from logic and to keep a consistent style among daemon scripts.
 +
* Use functions in {{ic|/etc/rc.d/functions}} instead of duplicating their functionality.
 +
* Include at least start, stop and restart as arguments to the script.
 +
 
 +
=== Available functions ===
 +
 
 +
* There are some functions provided by {{ic|/etc/rc.d/functions}}:
 +
** {{Ic|stat_busy "''message''"}}: set status ''busy'' for printed message (e.g. <nowiki>Starting daemon  [BUSY]</nowiki>)
 +
** {{Ic|stat_done}}: set status ''done'' (e.g. <nowiki>Starting daemon  [DONE]</nowiki>)
 +
** {{Ic|stat_fail}}: set status ''failed'' (e.g. <nowiki>Starting daemon  [FAILED]</nowiki>)
 +
** {{Ic|get_pid ''program''}}: get PID of the program
 +
** {{Ic|ck_pidfile ''PID-file'' ''program''}}: check whether PID-file is still valid for the program (e.g. <nowiki>ck_pidfile /var/run/daemon.pid daemon || rm -f /var/run/daemon.pid</nowiki>)
 +
** {{Ic|<nowiki>[add|rm]_daemon</nowiki> ''program''}}: add/remove program to running daemons (stored in {{ic|/run/daemons/}})
 +
 
 +
Full list of functions is much longer and most possibilities (like way to control whether or not non-root users can launch daemon) are still undocumented and can be learned only from {{ic|/etc/rc.d/functions}} source. See also {{Ic|man rc.d}}.
 +
 
 +
=== Example ===
 +
 
 +
The following is an example for ''crond''. Look in {{ic|/etc/rc.d}} for greater variety.
 +
 
 +
The configuration file:
 +
{{hc|/etc/conf.d/crond|2=<nowiki>ARGS="-S -l info"</nowiki>}}
 +
 
 +
The actual script:
 +
{{hc|/etc/rc.d/crond|2=<nowiki>
 +
#!/bin/bash
 +
 
 +
. /etc/rc.conf
 +
. /etc/rc.d/functions
 +
 
 +
DAEMON=crond
 +
ARGS=
 +
 
 +
[ -r /etc/conf.d/$DAEMON ] && . /etc/conf.d/$DAEMON
 +
 
 +
PID=$(get_pid $DAEMON)
 +
 
 +
case "$1" in
 +
start)
 +
  stat_busy "Starting $DAEMON"
 +
  [ -z "$PID" ] && $DAEMON $ARGS &>/dev/null
 +
  if [ $? = 0 ]; then
 +
    add_daemon $DAEMON
 +
    stat_done
 +
  else
 +
    stat_fail
 +
    exit 1
 +
  fi
 +
  ;;
 +
stop)
 +
  stat_busy "Stopping $DAEMON"
 +
  [ -n "$PID" ] && kill $PID &>/dev/null
 +
  if [ $? = 0 ]; then
 +
    rm_daemon $DAEMON
 +
    stat_done
 +
  else
 +
    stat_fail
 +
    exit 1
 +
  fi
 +
  ;;
 +
restart)
 +
  $0 stop
 +
  sleep 1
 +
  $0 start
 +
  ;;
 +
*)
 +
  echo "usage: $0 {start|stop|restart}" 
 +
esac
 +
</nowiki>}}
 +
 
 +
== Migration to systemd ==
 +
 
 +
{{Merge|Init|2012 installation media are of no relevance, merge remainders to [[Init]]}}
 +
 
 +
{{Note|
 +
* {{Pkg|systemd}} and {{Pkg|systemd-sysvcompat}} are both installed by default on installation media newer than [https://www.archlinux.org/news/systemd-is-now-the-default-on-new-installations/ 2012-10-13]. This section is aimed at Arch Linux installations that still rely on ''sysvinit'' and ''initscripts''.
 +
* If you are running Arch Linux inside a VPS, please see [[Virtual Private Server#Moving your VPS from initscripts to systemd]].
 +
}}
 +
 
 +
=== Considerations before switching ===
 +
 
 +
* Interactive ''initscripts'' do not work with ''systemd''.
 +
 
 +
=== Supplementary information ===
 +
 
 +
* It is not necessary to add your user to [[groups]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) for most use cases with systemd. The groups can even cause some functionality to break. For example, the {{ic|audio}} group will break fast user switching and allows applications to block software mixing. Every PAM login provides a logind session, which for a local session will give you permissions via [[Wikipedia:Access control list|POSIX ACLs]] on audio/video devices, and allow certain operations like mounting removable storage via [[udisks]].
 +
 
 +
== See also ==
  
==External Links==
+
* [[wikipedia:Init|Wikipedia: Init]]
* [http://en.wikipedia.org/wiki/Init Wikipedia: Init]
+
 
* [http://www.linux-tutorial.info/modules.php?name=MContent&pageid=65 Linux Knowledge Base and Tutorial. Run Levels.]
 
* [http://www.linux-tutorial.info/modules.php?name=MContent&pageid=65 Linux Knowledge Base and Tutorial. Run Levels.]
 
* [http://www.linux.com/articles/114107 Linux.com. Introduction to runlevels and inittab]
 
* [http://www.linux.com/articles/114107 Linux.com. Introduction to runlevels and inittab]
 
* [http://www.linux.com/news/enterprise/systems-management/8116-an-introduction-to-services-runlevels-and-rcd-scripts Linux.com. An introduction to services, runlevels, and rc.d scripts.]
 
* [http://www.linux.com/news/enterprise/systems-management/8116-an-introduction-to-services-runlevels-and-rcd-scripts Linux.com. An introduction to services, runlevels, and rc.d scripts.]

Latest revision as of 20:26, 16 June 2016

Related articles

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements.Tango-edit-clear.png

Reason: Blog-like writing, duplicate information (Discuss in Talk:SysVinit#)

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: Needs to be checked against initscripts-forkAUR (Discuss in Talk:SysVinit#)
Warning: SysVinit is not officially supported in Arch Linux [1].

On systems based on SysVinit, init is the first process that is executed once the Linux kernel loads. The default init program used by the kernel is /sbin/init provided by systemd-sysvcompat (by default on new installs, see systemd) or sysvinitAUR. The word init will always refer to sysvinit in this article.

inittab is the startup configuration file for init located in /etc. It contains directions for init on what programs and scripts to run when entering a specific runlevel.

Although a SysVinit-based Arch system does use init, most of the work is delegated to the #Main Boot Scripts. This article concentrates on init and inittab.

Installation

Install sysvinitAUR initscripts-forkAUR from the AUR. This step will remove systemd-sysvcompat, and you will use sysvinit on reboot. To restore systemd, append init=/usr/lib/systemd/systemd to the kernel command line.

Additional init scripts are available at arch-rcscripts. See Init#Configuration for generic configuration steps.

Overview of init and inittab

init is always process 1 and, other than managing some swap space, is the parent process to all other processes. You can get an idea of where init lies in the process hierarchy of your system with pstree:

$ pstree -Ap
init(1)-+-acpid(3432)
        |-crond(3423)
        |-dbus-daemon(3469)
        |-gpm(3485)
        |-mylogin(3536)
        |-ngetty(3535)---login(3954)---zsh(4043)---pstree(4326)
        |-polkitd(4033)---{polkitd}(4035)
        |-syslog-ng(3413)---syslog-ng(3414)
        `-udevd(643)-+-udevd(3194)
                     `-udevd(3218)

Besides usual initialization of system (as the name suggests), init also handles rebooting, shutdown and booting into recovery mode (single-user mode). To support these, inittab groups entries into different runlevels. The runlevels Arch uses are 0 for halt, 1 (aliased as S) for single-user mode, 3 for normal booting (multi-user mode), 5 for X and 6 for reboot. Other distros may adopt other conventions, but the meanings of 0, 1 and 6 are universal.

Upon execution, init scans inittab and carry out appropriate actions. An entry in inittab takes the form

id:runlevels:action:process

Where id is a unique identifier for the entry (just a name, no real impact on init), and runlevels is a (not delimited) string of runlevels. If the runlevel init is entering appears in runlevels, action is carried out, executing process if appropriate. Some special actions would cause init to ignore runlevels and adopt a special matching method. More explanation follows in the next section.

See also man 5 inittab and man 8 init.

Switching runlevel

Through bootloader

To change the runlevel the system boots into, simply add the desired runlevel n to the respective bootloader's configuration line. A common application of this is Start X at login#inittab. To boot to the desired runlevel, add its number to the kernel parameters (e.g. 3 for runlevel 3).

The run-level was appended to the end so the kernel knows what run-level to start with. To use another init program (e.g. systemd), add init=/bin/systemd or similar.

Note: If using some init other than sysvinit, the runlevel parameter might be ignored.

After boot up

After the system has booted up, you may issue telinit n to inform init to change the runlevel to n. init then reads inittab and "diffs" runlevel n and current runlevel - killing processes not present in the new runlevel and carrying out actions not present in the old runlevel. Processes present in both runlevels are left untouched. The killing procedure is actually a little complex; again, technical details can be found in the init manpage.

init doesn't watch inittab. You need to call telinit explicitly to apply modifications to inittab. The command telinit q causes init to re-examine inittab but not switch runlevel.

inittab

In this section we examine common entries in inittab, in the same order as they appear in the default inittab used by Arch. After that there are a few examples to help you create your own inittab entry.

Warning: Always test a modified /etc/inittab with telinit q before you reboot, or a small syntax error can prevent your system from booting.

Default Runlevel

The default runlevel is 3. Uncomment or add this if you prefer to boot into runlevel 5 (which is used for X conventionally) by default:

id:5:initdefault:

Main Boot Scripts

These are the main Arch init scripts.

rc::sysinit:/etc/rc.sysinit
rs:S1:wait:/etc/rc.single
rm:2345:wait:/etc/rc.multi
rh:06:wait:/etc/rc.shutdown

Single User Boot

Sometimes your kernel may fail to boot up all the way, due to a corrupted or dead hard drive or filesystem, missing key files, etc. In that case your init image may automatically enter into single-user mode which only allows root login and uses /sbin/sulogin instead of /sbin/login to control the login process. You can also boot into single-user mode by appending the letter S to your kernel command line in your GRUB, LILO, or syslinux configuration. If you would like something other than sulogin to run, specify it here.

su:S:wait:/sbin/sulogin -p

Gettys and Login

These are crucial entries that run the gettys on your terminals. Most default configurations will have several gettys running on ttys1-6 which is what pops up on your screen with the login prompt. Also see openvt, chvt, stty, and ioctl.

c1:234:respawn:/sbin/agetty 9600 tty1 xterm-color
c5:5:respawn:/sbin/agetty 57600 tty2 xterm-256color

Ctrl+Alt+Del

When the special key sequence Ctrl+Alt+Del is pressed, this determines what to do.

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

X Programs

If you are not afraid to debug, you can figure out how to start all sorts of programs from inittab. One useful type of program is to start your login manager when the runlevel is 5, multi-user-x-mode. In the following example you can see how to start SLiM when entering runlevel 5.

x:5:respawn:/usr/bin/slim >/dev/null 2>&1
#x:5:respawn:/usr/bin/xdm -nodaemon -confi /etc/X11/xdm/archlinux/xdm-config

Power-Sensing Scripts

Init can communicate with your UPS device and execute processes based on the status of the UPS. Here are some examples:

pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"

Custom Keyboard Request

The following line adds a custom function for when a special key sequence is pressed. You can modify this special key sequence to be anything you like, similar to a Ctrl+Alt+Del.

kb::kbrequest:/usr/bin/wall "Keyboard Request -- edit /etc/inittab to customize"

Trigger the kbrequest

You can trigger the special key sequence kbrequest by sending the WINCH signal to the init process (1) as root (via sudo). In this example, the command:

kill -WINCH 1

Causes wall to write to all ttys:

Broadcast message from root@askapachehost (console) (Wed Oct 27 14:02:26 2010):
Keyboard Request -- edit /etc/inittab to customize

Writing rc.d scripts

Initscripts uses rc.d scripts to used to control the starting, stopping and restarting of daemons.

Guideline

  • Source /etc/rc.conf, /etc/rc.d/functions, and optionally /etc/conf.d/DAEMON_NAME.
  • Arguments and other daemon options should be placed in /etc/conf.d/DAEMON_NAME. This is done to separate configuration from logic and to keep a consistent style among daemon scripts.
  • Use functions in /etc/rc.d/functions instead of duplicating their functionality.
  • Include at least start, stop and restart as arguments to the script.

Available functions

  • There are some functions provided by /etc/rc.d/functions:
    • stat_busy "message": set status busy for printed message (e.g. Starting daemon [BUSY])
    • stat_done: set status done (e.g. Starting daemon [DONE])
    • stat_fail: set status failed (e.g. Starting daemon [FAILED])
    • get_pid program: get PID of the program
    • ck_pidfile PID-file program: check whether PID-file is still valid for the program (e.g. ck_pidfile /var/run/daemon.pid daemon || rm -f /var/run/daemon.pid)
    • [add|rm]_daemon program: add/remove program to running daemons (stored in /run/daemons/)

Full list of functions is much longer and most possibilities (like way to control whether or not non-root users can launch daemon) are still undocumented and can be learned only from /etc/rc.d/functions source. See also man rc.d.

Example

The following is an example for crond. Look in /etc/rc.d for greater variety.

The configuration file:

/etc/conf.d/crond
ARGS="-S -l info"

The actual script:

/etc/rc.d/crond
#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

DAEMON=crond
ARGS=

[ -r /etc/conf.d/$DAEMON ] && . /etc/conf.d/$DAEMON

PID=$(get_pid $DAEMON)

case "$1" in
 start)
   stat_busy "Starting $DAEMON"
   [ -z "$PID" ] && $DAEMON $ARGS &>/dev/null
   if [ $? = 0 ]; then
     add_daemon $DAEMON
     stat_done
   else
     stat_fail
     exit 1
   fi
   ;;
 stop)
   stat_busy "Stopping $DAEMON"
   [ -n "$PID" ] && kill $PID &>/dev/null
   if [ $? = 0 ]; then
     rm_daemon $DAEMON
     stat_done
   else
     stat_fail
     exit 1
   fi
   ;;
 restart)
   $0 stop
   sleep 1
   $0 start
   ;;
 *)
   echo "usage: $0 {start|stop|restart}"  
esac

Migration to systemd

Merge-arrows-2.pngThis article or section is a candidate for merging with Init.Merge-arrows-2.png

Notes: 2012 installation media are of no relevance, merge remainders to Init (Discuss in Talk:SysVinit#)
Note:

Considerations before switching

  • Interactive initscripts do not work with systemd.

Supplementary information

  • It is not necessary to add your user to groups (sys, disk, lp, network, video, audio, optical, storage, scanner, power, etc.) for most use cases with systemd. The groups can even cause some functionality to break. For example, the audio group will break fast user switching and allows applications to block software mixing. Every PAM login provides a logind session, which for a local session will give you permissions via POSIX ACLs on audio/video devices, and allow certain operations like mounting removable storage via udisks.

See also