telinit 8 administrator commands nosh
telinit chkconfig deb-systemd-invoke 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.

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

`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, -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

`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.

Unlike the BSD service 8 command, `service` can manually start and stop disabled services.

#### OpenBSD rc

`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.

#### OpenRC

`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

`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:

command1 | command2
show-config | show-json
start | start
status | status
stop | stop
version | version

No other functionality of the original `initctl` tool is supported.

#### Solaris SMF

`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:

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.

#### IRIX

`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:

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.

##### 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

`invoke-rc.d` name -q --quiet --user --skip-systemd-native start stop `update-rc.d` name -f --force --user enable disable remove defaults `deb-systemd-invoke` name -q --quiet --user start stop
Avoid using these commands outwith package installation/uninstallation scripts. They are tailored for such use in particular.

Invoked as either `invoke-rc.d` name command1 or `deb-systemd-invoke` 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 starting 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 --user option is simply passed through to system-control 1. The --quiet option has no translatable meaning, does nothing, and is present for compatibility only. The --skip-systemd-native option also 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:

command1 | command2
defaults | preset
start | preset
stop | preset
enable | preset
disable | disable
remove | disable

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.

The --user option is simply passed through to system-control 1. The --force option has no translatable meaning, does nothing, and is present for compatibility only.

### telinit server

`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.

This program speaks the control protocol of the van Smoorenburg init and telinit programs. That protocol is not compatible with
Joachim Wiberg's
(formerly
Nilsson
) 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.
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