Use telinit safely on a systemd Linux host

You will identify what the installed telinit can do, map its old runlevel vocabulary to systemd targets, and use its non-disruptive controls safely. This guide assumes a systemd host and takes about ten minutes. Several commands can shut down the machine or change its boot environment, so the examples begin with inspection and leave those actions as explicit warnings.

1. Confirm the installed implementation

telinit is not an independent SysV init system on a current systemd installation. The local manual describes it as a compatibility command whose requests are translated into systemd unit activation requests. Check the executable and package before relying on examples:

$ 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. The options and commands in this guide are the ones documented by the installed systemd 255 manual and shown by the installed binary, not a promise about an unrelated init implementation.

2. Read the local command help

Use the built-in help as a quick syntax check. This does not alter services 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

Help output can be reformatted by a later package revision. The useful check is that telinit exists and accepts --help without requiring elevated privileges.

3. Translate the old runlevel terms

On this system, the numeric commands are compatibility names for systemd operations:

Runlevel 2 through 5 are not guaranteed to have the historical SysV meaning you remember. Their exact unit relationships come from the host's installed target links and distribution configuration. Inspect the current target without changing it:

$ 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 status, as documented for telinit; check it immediately when a control request 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 systemd unit file, drop-in, or generator input and before starting a unit that depends on the new definition. This is a daemon configuration reload, not a restart of every service.

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

The first command is the compatibility spelling. The second is an explicit equivalent verification or operational alternative. Both require the authority needed to control the system manager. Do not reload merely because a service failed: first check the unit and journal so you know whether a file actually changed.

Reloading does not apply a changed service definition to a running process. For that, inspect the unit's documented restart or reload behaviour and make a separate, deliberate service operation.

5. Understand reexecution before using it

u or U asks systemd to reexecute its daemon and serialise, then restore, its state. It is not the same as rebooting and is not a general repair command. Use it only when you have a reason to reexecute the manager, such as a controlled systemd maintenance procedure:

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

Keep an administrative session available and check the result afterwards:

$ systemctl is-system-running
running

The result can instead be degraded, starting, or another state depending on the host. Do not treat a successful request as proof that every service is healthy. If a maintenance run goes wrong, inspect systemctl --failed and the journal with journalctl -b -p err; do not repeatedly reexecute without understanding the fault.

6. Treat rescue mode and power commands as service disruptions

The --no-wall option suppresses the wall message before reboot, halt, or power-off. It does not make those actions safer or less disruptive. Leave the default notification enabled unless a documented automation requirement says otherwise.

7. Diagnose the common mistakes

• If a numeric runlevel gives an unexpected service set, inspect the corresponding runlevelN.target and its dependencies. Do not assume old distribution-specific runlevel conventions still apply.
• If a request fails, capture the status and inspect the system manager's state with systemctl --failed and journalctl -b -p err. Root access cannot fix a misspelt command or an invalid target.
• If you changed a unit file but systemd does not see it, run sudo systemctl daemon-reload, then inspect with systemctl cat UNIT. Replace UNIT with an actual unit name; do not type the placeholder literally.
• If you only need to start, stop, restart, enable, or inspect one service, use the matching systemctl operation directly. telinit is retained for compatibility and has a deliberately small command set.