systemctl-restart
Restart a systemd service
TLDR
Restart a unit
Restart more than one unit
SYNOPSIS
systemctl [OPTIONS...] restart NAME...
PARAMETERS
NAME...
Specifies the name(s) of one or more systemd units to restart. Common examples include apache2.service
, nginx.service
, or dbus.socket
.
-H HOST, --host=HOST
Execute the operation on a remote host. This allows managing services on a different machine
via SSH or a similar mechanism.
-q, --quiet
Suppress most output messages from systemctl, useful for scripting or when output is not
desired.
--no-block
Do not wait for the operation to complete. The command will return immediately, allowing the
restart process to happen in the background.
--user
Communicate with the user systemd instance rather than the default system systemd instance.
This is used for managing services started by a specific user.
--system
(Default) Communicate with the system systemd instance. This manages system-wide services
and units.
-t TYPE, --type=TYPE
Only operate on units of the specified TYPE. For example, --type=service would only
consider units ending with .service
.
DESCRIPTION
The systemctl restart command is used to gracefully stop and then immediately start one or more
systemd units. This is a critical operation for applying configuration changes to a service,
re-initializing a service that might be in an unstable state, or simply ensuring a service is running
with its latest configuration. Unlike a manual `stop` followed by `start`, `restart` ensures that the
service is brought back online if it was previously active, and often handles underlying dependencies
more elegantly. It's an atomic operation in the sense that it combines both actions, minimizing the
window where the service is unavailable. If a service defines an `ExecReload` directive in its unit
file, systemctl reload might be a less disruptive alternative, but `restart` guarantees a full
reinitialization.
CAVEATS
- Most systemctl restart operations on system units require root privileges (e.g., using
sudo). - If a service fails to stop or start during the restart process, the command will report a failure.
Consult journalctl -u NAME for detailed logs. - For services that support it, systemctl reload is often preferred over restart as it
minimizes service downtime by only reloading configuration files without stopping the entire service.
Check the service's documentation or unit file for `ExecReload` support. - A successful `restart` command does not guarantee that the service is fully functional, only that
the `ExecStart` command was executed. Always check the service's status and logs.
UNIT FILES
systemd manages system resources through configuration files called unit files, typically
found in /etc/systemd/system/
or /lib/systemd/system/
. Each unit type (e.g., .service
, .socket
, .mount
) has specific directives defining its behavior. When restarting, you refer
to these units by their full name (e.g., ssh.service
).
IDEMPOTENCY
The systemctl restart command is generally idempotent in its desired outcome: regardless
of the service's current state (running or stopped), executing `restart` will attempt to bring the
service to a 'restarted and active' state.
DEPENDENCY HANDLING
systemd is designed with advanced dependency management. When you restart a service, systemd
considers the `Requires`, `Wants`, `Before`, and `After` directives within the service's unit file,
intelligently managing related units to ensure proper startup order and functionality.
HISTORY
systemctl is the primary command-line utility for controlling the systemd init system,
which became the default init system for many major Linux distributions starting in the early 2010s.
systemd replaced older systems like SysVinit and Upstart, aiming to improve boot times,
enhance service management, and provide robust dependency handling. The restart subcommand is a
core part of systemctl's service control capabilities, offering a standardized and efficient way
to reinitialize services across modern Linux environments.
SEE ALSO
systemctl start(1), systemctl stop(1), systemctl enable(1), systemctl disable(1), systemctl status(1), systemctl reload(1), journalctl(1)