Control Legacy Services Safely with service(8)

Plenty of servers still answer to service instead of pure systemctl, so know what it does before typing sudo service NAME restart at 2am. You will check a service, start or stop it when appropriate, pass a script-specific option, and confirm the result from the exit status. This is the compatibility command from the init-system-helpers package; the machine used here reports version 1.66ubuntu1.

Allow about 10 minutes for a first pass. You need a shell and a real service name on the host. Reading status is normally harmless. Starting, stopping, reloading or fully restarting a service changes the running system and usually needs root, so identify the target before you reach for sudo.

1. Confirm the command and choose a target

Check which implementation is installed and read its usage line:

command -v service
service --version
service --help

On this host, that gives:

/usr/sbin/service
service ver. 1.66ubuntu1
Usage: service < option > | --status-all | [ service_name [ command | --full-restart ] ]

The normal form is service SCRIPT COMMAND [OPTIONS]. The name can refer to a System V script in /etc/init.d or to a systemd unit, and the visible name will not tell you which. If both an init script and a systemd unit share the name, the systemd unit wins.

Checkpoint: you know the exact service name and whether your next move is an inspection or a state change.

2. Inspect one service without changing it

Use status first. It gets passed straight to the underlying implementation, so wording varies by script or unit:

service apparmor status

A running service commonly prints a line containing active or running and exits zero. A stopped one may print a stopped state and return non-zero. Capture that status in a script:

if service apparmor status >/tmp/apparmor-status.txt 2>&1; then
    echo "apparmor reports success"
else
    status=$?
    echo "apparmor status command returned $status"
fi
cat /tmp/apparmor-status.txt

The temporary file is just for this check and safe to delete once read. Do not treat a non-zero status as proof the service is broken: the status is whatever the underlying script or manager decided it means.

To survey old-style init scripts:

service --status-all

This runs status on SysV init jobs alphabetically. [ + ] means running, [ - ] means stopped, and [ ? ] means the script has no usable status command. It does not query systemd units at all, and it can be noisy on a busy host, so prefer the named check once you know the service.

3. Start or stop only the named service

Starting and stopping are privileged, service-disrupting operations. Before running either, check the name and think about active clients, dependencies and the maintenance window.

sudo service SERVICE_NAME start
sudo service SERVICE_NAME status

sudo service SERVICE_NAME stop
sudo service SERVICE_NAME status

Replace SERVICE_NAME with a real name, such as cron or apparmor. The status check straight after the change is your real checkpoint. If the start fails, keep the output and exit status before trying anything else:

sudo service SERVICE_NAME start
result=$?
printf 'service returned %s\n' "$result"
sudo service SERVICE_NAME status

Recovery: there is no universal undo beyond the opposite action. If you stopped a service by mistake, run sudo service SERVICE_NAME start once you have confirmed it is safe to restore. That will not bring back in-memory work or connections lost during the stop.

4. Reload configuration when the service supports it

Some services implement reload, asking the service to reread configuration without a full stop and start. service itself does not add that capability: what is supported depends on the script or unit underneath.

sudo service SERVICE_NAME reload
sudo service SERVICE_NAME status

Use reload only when the service's own documentation says it is supported. A script may reject it, silently ignore it, or report a failure. If you need a change applied and there is no reload action, schedule a restart rather than gamble on reload being equivalent.

5. Understand full restart before you use it

--full-restart is a special case. For an init script, service calls it first with stop then with start. That is a real interruption, not a status refresh, and it can drop connections or lose transient state.

sudo service SERVICE_NAME --full-restart
restart_result=$?
printf 'full restart returned %s\n' "$restart_result"
sudo service SERVICE_NAME status

Use it only when a complete restart is intentional. If the start phase fails, do not loop restarts hoping it clears up. Check the service's own logs and configuration, then restore the last known-good state or follow its specific recovery procedure.

6. Pass options to the underlying script carefully

Arguments after the command go straight to a SysV init script, unmodified. There is no common option set across every script, so check the target script's own documentation, or run its help action only if that action is actually documented.

sudo service SERVICE_NAME COMMAND OPTION

The placeholders above are deliberately literal: do not paste them expecting a useful result. One script might accept status with extra arguments, another might reject them outright. Keep the command and its arguments together in your change record so someone else can reproduce what happened.

Common traps

Done means