systemctl-reload-or-restart

Reload or restart a unit

$ systemctl reload-or-restart [unit]

$ systemctl reload-or-restart [pattern]

$ systemctl reload-or-restart [unit] --no-block

$ systemctl reload-or-restart [unit] --user

systemctl [OPTIONS...] {reload|restart} UNIT...

UNIT...
    One or more systemd unit names (e.g., apache2.service, nginx.service, network.target). The .service suffix can often be omitted for service units.

--no-block
    Do not wait for the operation to finish. The command will exit immediately after issuing the request, allowing the process to continue in the background.

--user
    Operate on the user's systemd instance. By default, systemctl operates on the system systemd instance, requiring root privileges for most service management tasks.

--system
    (Default) Operate on the system systemd instance. This is the default behavior and usually requires root privileges.

--fail
    Return a non-zero exit code if the requested operation fails (e.g., the service fails to start or reload successfully).

The systemctl command is the primary tool for controlling the systemd system and service manager. When managing running services, two crucial subcommands are reload and restart, each serving a distinct purpose for applying configuration changes.

The reload subcommand instructs a service to re-read its configuration files without completely stopping and starting the process. This approach is designed to be less disruptive, aiming to maintain service availability during configuration updates. However, its effectiveness depends entirely on whether the service's daemon is designed to support graceful reloading. Not all services implement this functionality, or they may only partially support it for certain configuration parameters.

Conversely, the restart subcommand performs a complete stop and subsequent start of the service. This ensures that the service fully re-initializes and loads all configuration changes from scratch. While more disruptive, causing a brief period of downtime for the service, restart guarantees that all new settings are applied and can resolve issues that a simple reload might miss or cannot handle. It is the go-to command for significant configuration changes or when a service doesn't support reloading.

Service-Dependent Reload: The success and extent of a reload operation are entirely dependent on how the specific service's daemon is coded. Many services may not support it, or only partially.

Disruptive Restart: A restart operation will momentarily stop the service, causing a brief period of unavailability or disruption for users or applications relying on it.

Permissions: Managing system services with systemctl reload or restart typically requires root privileges (e.g., using sudo).

Configuration Errors: Applying new configuration via reload or restart with syntax errors will likely cause the operation to fail, potentially leaving the service in a stopped state if it was a restart.

Persistent Changes: systemctl commands only affect the running state. To make changes persistent across reboots, the configuration files themselves must be edited.

Use systemctl reload for minor configuration changes that do not fundamentally alter the service's architecture or resource allocation. Examples include updating log rotation settings, changing minor tuning parameters, or adding new virtual hosts to a web server without modifying its core listening ports or modules. Always confirm if the specific service supports a graceful reload for the changes you are applying.

Opt for systemctl restart when applying significant configuration changes (e.g., changing listening ports, enabling/disabling major modules, altering fundamental service behavior), when the service does not support reload, or when a reload does not seem to take effect. It's also the go-to command for troubleshooting an unstable service or applying security patches that require a full service re-initialization.

The concepts of reloading and restarting services predate systemd, existing in older init systems like SysVinit and Upstart (e.g., using service apache2 reload). However, systemd, introduced to many Linux distributions as the default init system, standardized these operations under the systemctl command. Its adoption marked a significant shift towards a more unified and powerful service management framework, replacing disparate init scripts with declarative unit files and providing a consistent interface through systemctl for operations like starting, stopping, reloading, and restarting services.

systemctl(1), journalctl(1), systemd(1), service(8)