systemctl-stop

Stop a unit

$ systemctl stop [unit]

$ systemctl stop --no-warn [unit]

systemctl stop [OPTIONS...] UNIT...

--no-block
    Don't wait for the operation to finish. This option causes systemctl to exit immediately after sending the stop request, without waiting for the unit to actually stop. The operation will continue in the background.

--no-wall
    Do not send wall message. Suppresses the sending of a wall message (a broadcast message to all logged-in users) that would normally occur for certain critical operations.

UNIT...
    The name(s) of the unit(s) to stop. This argument specifies one or more systemd unit names (e.g., nginx.service, apache2.service). The suffix (e.g., .service) is often optional if it's clear from context.

systemctl stop is a fundamental command in the systemd suite, used to terminate one or more active systemd units. When executed, it sends a stop signal (typically SIGTERM) to the processes associated with the specified unit, allowing them to perform a graceful shutdown. This command is versatile, capable of stopping various unit types including services (.service), sockets (.socket), mount points (.mount), and devices (.device).

Its primary function is to change the current operational state of a unit from "active" to "inactive." This is crucial for system administrators performing maintenance, troubleshooting, or resource management. For instance, stopping a web server service might be necessary before applying updates or reconfiguring it. It's important to note that systemctl stop only affects the runtime state and does not alter the unit's configuration for automatic startup on boot; for that, systemctl disable is required.

The command often requires root privileges to stop system-level services. While it aims for a graceful shutdown, if a unit fails to stop within a defined TimeoutStopSec, systemd may escalate by sending a SIGKILL to forcefully terminate the processes. Understanding unit dependencies is also vital, as stopping one unit might trigger the stopping of other units that depend on it.

Root Privileges: Most system-level services require root privileges (or `sudo`) to be stopped. Attempting to stop them without sufficient permissions will result in an error.
System Stability: Stopping critical system services can lead to instability or make the system unusable. Always ensure you understand the implications before stopping a service.
Dependencies: Stopping a unit may automatically stop other units that depend on it. systemctl automatically resolves and manages these dependencies.
Automatic Restart: Stopping a service does not prevent it from automatically restarting if its unit file is configured with Restart=always or similar. For persistent shutdown, consider disable or mask.
Runtime Only: This command affects the current runtime state only. It does not prevent the service from starting again on the next boot if it's enabled. Use systemctl disable to prevent automatic startup.

When systemctl stop is invoked, systemd intelligently manages unit dependencies and conflicts. If a unit is configured with Wants= or Requires= clauses, stopping a required unit will cause systemd to also stop the dependent units. Conversely, if a unit Conflicts= with another, stopping one might be necessary before starting the other, though stop itself usually resolves "conflicts" by just stopping the requested unit.

Systemd first attempts a graceful shutdown by sending SIGTERM to the unit's main process. This allows the application to clean up resources and save state. If the unit does not terminate within the time specified by TimeoutStopSec= (defaulting to 90 seconds), systemd then sends SIGKILL to forcefully terminate the processes, which can lead to data loss or corruption if the application hasn't saved its state.

The systemctl command is the primary control interface for systemd, which was introduced as a modern replacement for the traditional SysVinit and Upstart init systems in many Linux distributions. Developed by Lennart Poettering and Kay Sievers, systemd gained widespread adoption starting around 2010. The systemctl stop command emerged as part of this shift, providing a unified and consistent way to manage service lifecycle operations, replacing a disparate set of init.d scripts or service commands found in older systems. Its design focuses on efficient dependency management and parallelization during boot.

systemctl(1), systemctl start(1), systemctl enable(1), systemctl disable(1), systemctl status(1), systemctl restart(1), journalctl(1)