Name

telinit, init, reboot, halt, haltsys, powercycle, poweroff, emergency, rescue, normal, fastboot, fasthalt, fastpowercycle, fastpoweroff, service, rcctl, chkconfig, update-rc.d, invoke-rc.d, runlevel — BSD/System 5 compatibility utilities for system and service control

Description

telinit is a multiple personality program, whose function varies according to what name it is invoked as.

The various commands that it provides are compatibility shims only; they do not support the full capabilities of the original commands, only a common-use subset for providing an easy migration path for old BSD and System 5 habits and scripts. Avoid using them if possible.

It is preferable, although not ideal, to have systemd and upstart habits and use the systemctl(1) and initctl(1) compatibility commands instead.

Compatibility system control commands

These commands are all shims around system-control(1), either directly or indirectly via shutdown(8).

General

telinit [args...]

init [args...]

runlevel

Invoked as telinit args... or as init args... the program chains to system-control init args... , the behaviour of which is documented in system-control(1).

No attempt is made to validate args ; however it must have the same form as is used by the loader and kernel to pass arguments to process #1 at bootstrap. See the init subcommand of system-control(1) for details.

It is a mistake to run this as process #1, thinking that it is an alias for system-manager(8). It is not, and on some systems the executable is dynamically linked to libraries in /usr/lib which isn't present at boot time. Configure the system to invoke system-manager(8) directly, optionally under the name init, instead.

It is likewise a mistake to run this thinking that it is an alias for per-user-manager(8). Again, invoke that directly, optionally under the name init.

Invoked as runlevel, this simply prints "N" twice, to indicate that runlevels do not exist. This command exists for compatibility with some badly-written package installation/uninstallation scripts. It doesn't print "unknown", because those scripts are so badly written that they cannot even cope with runlevel not emitting two words. Do not use this obsolete command.

Startup

emergency

rescue

normal

Invoked as one of the system control commands emergency, rescue, or normal, it will chain to system-control(8) inserting that as the 0th argument and passing the original arguments as the subcommand.

Shutdown

reboot [ -f | --force ] [--halt] [--reboot] [--powercycle] [--poweroff]

halt [ -f | --force ] [--halt] [--reboot] [--powercycle] [--poweroff]

powercycle [ -f | --force ] [--halt] [--reboot] [--powercycle] [--poweroff]

poweroff [ -f | --force ] [--halt] [--reboot] [--powercycle] [--poweroff]

Invoked as one of the system control commands reboot, halt, powercycle, or poweroff it will normally chain to shutdown(8) with the -r , -h , or -p command-line option respectively. shutdown(8) is then responsible for issuing the relevant commands to the system manager. The --halt , --reboot , --powercycle , and --poweroff command-line options force which option is sent to shutdown(8), for the benefits of system administrators who enjoy giving computers self-contradictory instructions like reboot --halt .

The --force command-line option specifies that the shutdown process should bypass service changes and enact the finalization action immediately. When it is used the command will instead chain to the {reboot}, {halt}, {powercycle}, and {poweroff} subcommands of system-control(8), passing the --force command-line option through. This will also bypass whatever actions shutdown(8) would have taken, including writing warning messages to users and writing login accounting database entries.

Invoked as one of the system control commands fastboot, fasthalt, fastpowercycle, or fastpoweroff, it will act as if invoked as reboot, halt, powercycle, or poweroff with the --force command-line option.

haltsys is an alias for halt provided for rough compatibility with the XENIX and UnixWare extensions to System 5. It does not support their -d option, whose behaviour is strongly tied to those particular platforms.

Compatibility service control and configuration commands

These commands are all shims around system-control(1). As such, they all operate on native nosh services, not on old BSD or System 5 shell scripts. Their actions are defined in terms of service management actions, not in terms of running shell scripts. For example: service name start has the meaning of starting a named service, not of invoking a shell script with an argument.

These commands and will enforce correct service dependencies and start/stop orderings, unlike the original BSD and System 5 service management systems. For individual control of services without orderings or dependencies, use service-control(1) or service-status(1) directly instead.

Maintainer script utilities

invoke-rc.d {name} [ -q | --quiet ] { start | stop }

update-rc.d {name} [ -f | --force ] { enable | disable | remove | defaults }

Avoid using these commands outwith package installation/uninstallation scripts. They are tailored for such use in particular.

Invoked as invoke-rc.d name command1 , the program chains to system-control command2 name . command1 may only be one of start or stop , which are translated to reset and stop (respectively) for command2. The behaviour that it is designed to be backwards compatible with only starts a service in response to the start subcommand if the administrator has configured the service to auto-start. Hence the replacement of start by reset .

The --quiet option has no translatable meaning, does nothing, and is present for compatibility only.

Invoked as update-rc.d name command1 , the program chains to system-control command2 name , translating as in the following table. Again, the behaviour that it is designed to be backwards compatible with only enables a service in response to the enable subcommand if the administrator has configured the service to auto-start. Hence the use of preset .

Sub-command translation:
command1command2
defaults preset
start
stop
enable
disable disable
remove

The --force option has no translatable meaning, does nothing, and is present for compatibility only. Note also that the original update-rc.d tool eliminated all support for non-LSB-header-based System 5 rc, in July 2013. The defaults , start , and stop subcommands do not take arguments even in the original tool; and uses of the latter two subcommands should be replaced by the former.

Old-style service control

service [--verbose] {name} {command}

Invoked as service name command , the program chains to system-control command name , passing along any --verbose option. It makes no attempt itself to validate command, which can be any of the subcommands supported by system-control(1). However, for best results restrict command to one of start , stop , or status .

Note that, unlike the BSD command, service can manually start and stop disabled services.

Old-style Linux service control

chkconfig {name}

chkconfig {name} { reset | on | off }

Invoked as chkconfig name , the program chains to system-control is-enabled name .

Invoked as chkconfig name command1 , the program chains to system-control command2 name . command1 may only be one of reset , on , or off , which are translated to preset , enable , and disable (respectively) for command2.

No other functionality of the original chkconfig tool (whose operation varies incompatibly from platform to platform outwith these two subcommands) is supported.

OpenBSD service control

rcctl {command} {name}

Invoked as rcctl command name , unless command is either set or get the program chains to system-control command name . It makes no attempt itself to validate command, which can be any of the subcommands supported by system-control(1). set is replaced with set-service-env . get is replaced with print-service-env .

Do not use rcctl set name status to enable or disable services. This is not even correct for the original tool, as only OpenBSD uses variables named name_status in the first place. Other BSDs have different names which won't work with this OpenBSD-specific syntax. In contrast, rcctl enable name and rcctl disable name , defined as equivalents in the original OpenBSD tool, will work portably.

telinit server

initctl-read

initctl-read is a UCSPI telinit server. It loops forever, reading telinit request messages and executing the requested telinit commands. Almost no programs expect or use this interface, which the maintainers of the System 5 init package themselves consider to be private and deprecated.

It expects file descriptor 3 to be a FIFO that has been set up, with fifo-listen(1) or similar, to listen for incoming messages. Usually, its standard error will be redirected to an instance of cyclog(1) or similar.

Although the telinit requests protocol defines a wide range of requests, all are dishonoured except for runlevel changes, which are simply passed over to telinit for enacting. No validation is made on the run level requested except that it be a printable character.

Author

Jonathan de Boyne Pollard