systemctl-reload

Reload a service

$ systemctl reload [nginx]

$ systemctl reload [unit1 unit2 ...]

$ systemctl reload [pipewire] --user

systemctl reload [OPTIONS...] UNIT...

UNIT...
    One or more names of systemd units to be reloaded (e.g., nginx.service, firewalld.service). These units must be active and capable of being reloaded.

-H <host>, --host=<host>
    Execute the operation on a remote host via SSH. The host can be specified as a hostname, IP address, or user@host.

-M <container>, --machine=<container>
    Execute the operation on a local container. The container name or ID specifies the target environment.

--no-block
    Do not wait for the requested operation to finish. The command will return immediately after sending the reload request.

--user
    Operate on the systemd instance of the calling user. By default, systemctl operates on the system-wide instance, which usually requires root privileges for managing services.

--system
    Explicitly operate on the systemd system instance. This is the default behavior if --user is not specified and the command is run with appropriate permissions.

The systemctl reload command is a crucial utility within the systemd init system, designed to instruct one or more specified units (services, sockets, etc.) to re-read their configuration files and apply changes without undergoing a full restart. This is particularly valuable for maintaining high availability and minimizing downtime for critical services like web servers (e.g., Nginx, Apache HTTP Server), database servers, or logging daemons.

When you execute systemctl reload <unit_name>, systemd typically sends a SIGHUP (Hangup) signal to the main process of the target service. Well-behaved services are designed to catch this signal, parse their updated configuration files, and dynamically apply the new settings while continuing to operate, thus avoiding any interruption to ongoing operations or active connections.

It's important to differentiate reload from restart. While restart terminates the service process and then starts a new one (potentially causing a brief outage), reload aims for a seamless update. However, not all services support graceful reloading. If a service does not handle the SIGHUP signal for config reloads, systemctl reload may fail, have no effect, or even lead to an inconsistent state, in which case a full restart would be necessary. Always consult the documentation for the specific service to understand its reload behavior.

Service Support: Not all services support graceful reloading. If a service does not handle the SIGHUP signal for configuration reloads, systemctl reload will likely fail or have no effect, requiring a systemctl restart instead.
Configuration Errors: Introducing syntax errors or invalid configurations into a service's configuration file before reloading can cause the reload to fail, or worse, put the service into an unrecoverable state without a full restart.
Partial Reloads: Some complex services might only reload certain configuration aspects with reload, while others might require a full restart for more significant or foundational changes.
Permissions: Reloading system services typically requires root privileges (e.g., using sudo).

When systemctl reload is invoked, systemd primarily communicates with the service by sending the SIGHUP (Hangup) signal to its main process. Services that support reloading are programmed to intercept this signal, re-read their configuration files (e.g., /etc/nginx/nginx.conf), and apply the changes without terminating active processes or connections. This method ensures minimal disruption.

For services where it's uncertain if they support graceful reloading, or to provide a robust fallback, systemd offers the systemctl reload-or-restart <unit_name> command. This command first attempts to reload the service. If the reload operation fails or is not supported by the service, it automatically falls back to performing a full restart, ensuring that the new configuration is applied one way or another.

The systemctl command is a core component of systemd, which was first introduced in 2010 to replace traditional init systems like SysVinit and Upstart. The concept of gracefully reloading service configurations using signals like SIGHUP predates systemd, being a long-standing practice in Unix-like environments for daemon management. Systemd integrated this pattern into its unified service management framework, providing the standardized systemctl reload command. Its adoption has made it the primary method for managing service lifecycles and configuration updates on modern Linux distributions, emphasizing stability and ease of administration.

systemctl(1), systemctl-restart(8), systemctl-start(8), systemctl-stop(8), systemctl-status(8), kill(1), daemon(7)