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
telinit is a multiple personality program, whose function varies according to what name it is invoked as.
Or one can just use the system-control(1) command directly.
These commands are all shims around system-control(1), either directly or indirectly via shutdown(8).
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.
/usr/lib which isn't present at boot time.
Configure the system to invoke system-manager(8) directly, optionally under the name init, instead.
Invoked as runlevel, this simply prints "N" twice, to indicate that runlevels do not exist.
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.
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.
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.
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.
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 .
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.
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.
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.
command1 | command2 |
| show-config | show-json |
| start | start |
| status | status |
| stop | stop |
| version | version |
No other functionality of the original initctl tool is supported.
svcadm { version | enable | disable } {name}
Invoked as svcadm command1 name , the program chains to system-control command2 name , translating as in the following table.
command1 | command2 |
| 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.
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.
command1 | command2 |
| 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.
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.
invoke-rc.d {name} [ -q | --quiet ] { start | stop }
update-rc.d {name} [ -f | --force ] { enable | disable | remove | defaults }
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 .
command1 | command2 |
| 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.
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.
SIGPWR to process #1, writing the power event to /run/powerstatus or equivalent (depending from the operating system), instead.