Name

telinit, chkconfig, emergency, fastboot, fasthalt, fastpowercycle, fastpoweroff, halt, haltsys, init, initctl, invoke-rc.d, normal, powercycle, poweroff, rc-service, rc-update, rcctl, reboot, rescue, runlevel, service, svcadm, update-rc.d — BSD, System 5, and SunOS 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.

Caution

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.

Or one can just use the system-control(1) command directly.

Compatibility system control commands

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

General

Synopsis

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.

Warning

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.

Warning

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.

Caution

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

Synopsis

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

Synopsis

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 , -c , 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.

Generic

Synopsis

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 service(8) command, service can manually start and stop disabled services.

OpenBSD rc

Synopsis

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 .

Caution

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.

OpenRC

Synopsis

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

rc-update { add | delete } {name}

Invoked as rc-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 .

Invoked as rc-update command1 name , the program chains to system-control command2 name . command1 may only be one of add or del , which are translated to preset and disable (respectively) for command2.

Upstart

Synopsis

initctl { version | start | stop | status | show-config } {name}

Invoked as initctl command1 name , the program chains to system-control command2 name , translating as in the following table.

Sub-command translation:
command1command2
show-config show-json
start start
status status
stop stop
version version

No other functionality of the original initctl tool is supported.

Solaris SMF

Synopsis

svcadm { version | enable | disable } {name}

Invoked as svcadm command1 name , the program chains to system-control command2 name , translating as in the following table.

Sub-command translation:
command1command2
disable stop
enable start
version version

No other functionality of the original svcadm tool is supported. For the milestone subcommand, start the appropriate combination of standard targets. There is no simple 1:1 correspondence between standard targets and SMF milestone names.

IRIX

Synopsis

chkconfig {name}

chkconfig [ -f | --force ] {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 , translating as in the following table.

Sub-command translation:
command1command2
reset preset
on enable
off disable

The --force option has no translatable meaning, does nothing, and is present for compatibility only. The IRIX chkconfig(1M) tool manipulated (possibly non-existent) flag files in /var/config and required a flag to force the creation of non-existent files. This has no meaning with system-control(8). Conversely, reset has no meaning for the IRIX original, where flag files had no "preset" information to be initialized from.

The remaining functionality of the IRIX chkconfig(1M) tool, without any name argument and with an optional -s option, is not supported at all. There is no one big central state directory used by system-control(8) to list. Rather, enable/disable states are distributed around the service bundle directories, and are relative to one or more targets.

History

This is a shim for the IRIX command by this name. The IRIX original had no concept of preset information, and was purely an access method for named on/off configuration flag files which theoretically had any use one liked. It was conceptually like the flags in the BSD rc.conf(5) system, which have arbitrary uses (but which can, however, represent more than on/off boolean data, which the IRIX system was limited to).

Miquel van Smoorenberg wrote a similar tool, that used and altered completely different configuration information for van Smoorenberg's rc(8) system. It was limited to solely service enable/disable states, and no longer supported arbitrary uses for named flags. van Smoorenberg's chkconfig(8) added a different command-line syntax, not in the IRIX original, which is not supported by this command. They have only the original IRIX syntax in common, along with the reset argument, which is a van Smoorenberg addition to the IRIX original that took preset information held in comments in rc(8) scripts. (The added, different, van Smoorenberg syntax was for adding and removing services, rather than enabling and disabling them, which has no translatable meaning.)

That then in turn inspired Joe Oppegaard's sysv-rc-conf(8). Oppegaard's sysv-rc-conf(8) altered the original IRIX syntax incompatibly, and is thus wholly incompatible with both this command and the IRIX original.

Erik Troan's chkconfig(8) tool for CentOS/RedHat expanded upon van Smoorenberg's added, different, syntax; and again has only the original IRIX syntax (plus the van Smoorenberg reset ) in common with this command. Michael Schroeder's chkconfig(8) tool for SuSE discarded all of the original IRIX syntax, leaving the van Smooorenberg added different one, and thus has no common syntax with this command.

Debian maintainer script utilities

Synopsis

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

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

Caution

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 preset
stop preset
enable preset
disable disable
remove disable

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.

telinit server

Synopsis

initctl-read

initctl-read is a UCSPI telinit server. 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.

It loops forever, reading request messages and executing the requested commands. Although the van Smoorenburg telinit requests protocol defines a wide range of requests, all are dishonoured except for runlevel changes, which are (in a reversal of the van Smoorenburg system) simply passed over to telinit for enacting, which in turn hands them over to system-control init as explained in a preceding section. No validation is made on the run level requested except that it be a printable character.

Caution

This program speaks the control protocol of the van Smoorenburg init and telinit programs. That protocol is not compatible with Joachim Nilsson's finit program, which has a similar FIFO. Almost no programs expect or use this interface, which the maintainers of the van Smoorenburg init package themselves consider to be private and deprecated.

Warning

Do not use this interface in power monitoring softwares. Send SIGPWR to process #1, writing the power event to /run/powerstatus or equivalent (depending from the operating system), instead.

Author

Jonathan de Boyne Pollard