systemctl-cancel

Cancel a job by its numeric ID

$ systemctl cancel [job_id]

$ systemctl cancel [job_id1 job_id2 ...]

$ systemctl cancel

$ systemctl cancel [job_id] --user

`systemctl cancel [PID...]`

`PID...`
    One or more Process IDs. When specified, `systemctl cancel` will send the `SIGKILL` signal to these processes, forcibly terminating them, and subsequently remove any systemd jobs associated with them from the queue. If no PIDs are provided, the command cancels *all* currently pending jobs in the systemd queue without affecting running processes.

`systemctl cancel` is a powerful command used to clear the systemd job queue. When invoked without any arguments, it will immediately cancel all pending jobs that are currently queued by systemd. This includes jobs like starting, stopping, restarting, or reloading units that have not yet begun execution or are waiting for dependencies. It's an important diagnostic and recovery tool, particularly useful when the system's startup or shutdown process gets stalled due to a hung or misbehaving service, or when the job queue becomes unresponsive.

Unlike `systemctl stop`, which attempts to gracefully terminate a running unit, `cancel` operates on the jobs themselves, preventing them from executing or removing them if they are stuck. When PIDs are specified, `systemctl cancel` will additionally send the SIGKILL signal to those processes, forcibly terminating them, and then remove any associated jobs from the queue. This can be critical for unblocking the system when specific processes are preventing further systemd operations.

• Disruptive Action: When used without PIDs, `systemctl cancel` clears all pending systemd jobs, which can disrupt planned system operations or services that were about to start or stop.
• Data Loss Risk (with PIDs): Sending `SIGKILL` to processes (when PIDs are specified) is a forceful termination that does not allow processes to perform cleanup or save data. This can lead to data corruption or loss for applications that do not handle sudden termination gracefully.
• State Inconsistency: Cancelling jobs, especially those related to system startup or critical service management, might leave the system in an inconsistent or undefined state.
• Requires Root Privileges: This command requires elevated privileges (root or sudo) to execute due to its potential impact on system-wide operations and processes.

Use this command as a last resort when the system is stuck in a state where systemd jobs are queued but not progressing, preventing normal operation, shutdown, or startup. Examples include:

• During boot or shutdown, if the system hangs waiting for a service to start or stop.
• When `systemctl status` shows services in a 'starting' or 'stopping' state indefinitely, blocking other operations.
• To clear a backlog of failed or hung jobs that are preventing further systemd actions.
• When specific processes are unresponsive and holding up systemd transitions, and a `SIGTERM` (via `systemctl stop` or `kill`) is ineffective.

Systemd manages units (services, mount points, devices, etc.) through a job queue. When you issue a command like `systemctl start my-service`, systemd creates a job and adds it to the queue. Dependencies are resolved, and jobs are executed in the appropriate order. `systemctl cancel` acts directly on this queue, removing jobs before they are executed or completed, allowing the system manager to potentially unblock itself.

The `systemctl` command is an integral part of systemd, the system and service manager that has become the default init system for most Linux distributions, replacing the older SysVinit. The `cancel` subcommand was introduced early in systemd's development lifecycle as a crucial mechanism for system administrators to recover from situations where the systemd job queue becomes stalled or unresponsive. Its functionality evolved to include the ability to target specific processes with `SIGKILL`, enhancing its utility as a forceful recovery tool for unresponsive services that block critical system operations like shutdown or startup. This reflects systemd's design philosophy of providing robust control and recovery capabilities for system services.

systemctl(1), systemctl status(1), systemctl stop(1), systemctl kill(1), kill(1), signal(7)