Use telinit Safely on a systemd Host

Someone hands you a runbook that says "run telinit 3" and the box has not had a real SysV init since 2015. This guide shows what telinit actually does on a modern systemd host, how to translate its old runlevel numbers, and where the genuinely dangerous commands hide. Allow about ten minutes: the first two steps are pure inspection, the rest change daemon state.

1. Confirm the installed implementation

telinit is not an independent SysV init on a current systemd installation. The local manual describes it as a compatibility shim: your request gets translated into a systemd unit activation. Check the binary and package before trusting any example, including this one:

$ command -v telinit
/usr/sbin/telinit
$ dpkg-query -W -f='${Package} ${Version}\n' systemd-sysv
systemd-sysv 255.4-1ubuntu8.17
$ systemctl --version | sed -n '1,2p'
systemd 255 (255.4-1ubuntu8.17)

The package version is distribution-specific. Everything below matches the installed systemd 255 manual and the installed binary, not a promise about some other init system you half-remember from an older box.

2. Read the local command help

telinit --help is a free syntax check: it does not touch a single service or send a control request.

$ telinit --help
telinit [OPTIONS...] COMMAND

Send control commands to the init daemon.

Commands:
  0              Power-off the machine
  6              Reboot the machine
  2, 3, 4, 5     Start runlevelX.target unit
  1, s, S        Enter rescue mode
  q, Q           Reload init daemon configuration
  u, U           Reexecute init daemon

Options:
     --help      Show this help
     --no-wall   Don't send wall message before halt/power-off/reboot

A later package revision can reformat this text. The useful check is simply that telinit exists and answers --help without needing elevated privileges.

3. Translate the old runlevel terms

On this host, every numeric command is a compatibility name for a systemd operation:

Runlevels 2 through 5 do not necessarily mean what you remember from a SysV box. Their real unit mapping comes from this host's target links and distribution configuration, so check rather than assume:

$ systemctl get-default
graphical.target
$ systemctl list-units --type=target --state=active

The active-target list varies by machine. A failed command returns a non-zero exit status, as the manual documents, so check it whenever a control request actually matters:

$ telinit --help > /dev/null
$ printf 'exit status: %s\n' "$?"
exit status: 0

4. Reload unit configuration when files changed

Use q or Q after adding or editing a unit file, drop-in, or generator input, before starting anything that depends on the new definition. This is a configuration reload, not a restart of every running service.

$ sudo telinit q
$ printf 'exit status: %s\n' "$?"
exit status: 0
$ systemctl daemon-reload

The first line is the compatibility spelling; the second is the explicit equivalent. Both need the authority to control the system manager. Do not reload just because a service failed: check the unit and journal first, so you actually know a file changed.

Reloading does not push a changed service definition into an already-running process. For that, check the unit's documented restart or reload behaviour and make a separate, deliberate service operation.

5. Understand reexecution before you use it

u or U asks systemd to reexecute its own daemon: serialise its state, then restore it. It is not a reboot and not a general repair command. Use it only when you have an actual reason, such as a planned systemd maintenance procedure:

$ sudo telinit u
$ printf 'exit status: %s\n' "$?"
exit status: 0

Keep an administrative session open and check the result afterwards:

$ systemctl is-system-running
running

The result can just as easily be degraded, starting, or something else. A successful request is not proof that every service is healthy. If a maintenance run goes wrong, check systemctl --failed and journalctl -b -p err. Do not reexecute again and again hoping it settles.

6. Treat rescue mode and power commands as service disruptions

--no-wall suppresses the warning message sent before reboot, halt, or power-off. It does not make the action itself any safer. Leave the default notification on unless a documented automation requirement says otherwise.

7. Diagnose the common mistakes

• Wrong service set after a runlevel switch. Inspect the corresponding runlevelN.target and its dependencies; do not assume old distribution-specific runlevel conventions still apply here.
• A request fails outright. Capture the status, then check systemctl --failed and journalctl -b -p err. Root access cannot fix a misspelt command or an invalid target.
• Systemd ignores a unit file you just edited. Run sudo systemctl daemon-reload, then check with systemctl cat UNIT, swapping in the real unit name rather than typing the placeholder literally.
• You only need one service handled. Use the matching systemctl operation directly (start, stop, restart, enable, status). telinit exists for compatibility and keeps a deliberately small command set.