Home / Alt manpages / cancel(1)

  • cancel(1)
  • User command
  • linux

Cancel CUPS Print Jobs Safely with cancel

Reach for cancel when a print job needs to die before the printer chews through fifty pages of the wrong file. Allow about ten minutes for a single cancellation. The commands here use the CUPS client installed on this machine, from cups-client version 2.4.7-1.2ubuntu7.14.

Cancellation changes the print queue. Read the target twice before pressing Enter, especially with -a. There is no general undo for a job already cancelled, and the optional -x is more destructive still: it also deletes the job's data files.

1. Confirm the client and inspect the queue

Start with read-only checks. You do not need elevated privileges to identify the client or ask CUPS for jobs:

$ command -v cancel
/usr/bin/cancel
$ dpkg-query -W -f='${Package} ${Version}\n' cups-client
cups-client 2.4.7-1.2ubuntu7.14
$ lpstat -o
printer-name-42  your-user  1024  Mon 22 Sep 2026 09:15:00 BST

That last output is host-specific. A job line normally shows a destination and an identifier such as printer-name-42. On a machine with no running scheduler, lpstat reports the scheduler is not running instead of listing jobs: fix that first, and never guess an identifier.

Checkpoint

Write down the complete job ID you intend to cancel and, if relevant, its destination and owner.

2. Cancel one known job

Pass the complete job ID to cancel. This is the narrowest normal operation:

$ cancel printer-name-42

A blank terminal is not proof the wrong job was selected. Check the queue again:

$ lpstat -o
# the cancelled job should no longer be listed

The exact confirmation and error text depend on the CUPS server and authentication policy. If the job was already printing, cancellation may stop it a moment after the server accepts the request, since printer hardware takes time to react. Keep the job ID and any error message if you need an administrator to investigate.

There is no local rollback here. If the document still needs printing, submit it again through the original command after checking the destination and printer state.

3. Cancel the current job on the default destination

With no destination or ID, cancel targets the currently printing job on the default destination:

$ cancel

This is the default that catches people out. It does not mean "cancel the last job I submitted" and it does not select every queue. Confirm which queue is the default and inspect the current jobs before using it. If you already know the job ID, the explicit form from step 2 is safer.

4. Limit cancellation by destination or owner

Use a destination name to cancel the current job on that destination:

$ cancel PRINTER_NAME

Printer and class names in CUPS ignore case but cannot contain spaces, tabs, a slash or a hash character. Use the name exactly as your queue tools show it, and quote it if the rest of your command may contain special characters.

-u selects jobs owned by a username:

$ cancel -u YOUR_USERNAME

Check the server's authorisation policy first: this requests cancellation of that user's jobs, it is not a harmless filter. A server may require authentication or refuse jobs belonging to another user. The CUPS administrator controls whether Cancel-Jobs is allowed across users, so do not work around a refusal with repeated guesses.

5. Cancel all jobs only after a deliberate check

-a cancels all jobs on the named destination, or every job on every destination if none is given:

$ cancel -a PRINTER_NAME

That disrupts the service for everyone using the queue. Confirm the destination, the owner impact and the maintenance window first. To cancel every queued job the server knows about:

$ cancel -a

Warning

Do not use this as a troubleshooting shortcut. Capture the queue listing first if you may need to explain what was removed later. There is no undo: affected users must resubmit their documents.

6. Choose connection and data-retention options carefully

For a remote CUPS server, put -h first, as the installed manual requires:

$ cancel -h print-server.example:631 printer-name-42

Replace the hostname and port with your own values. -E forces encryption for the connection, while -U YOUR_USERNAME supplies the username used for authentication:

$ cancel -h print-server.example:631 -E -U YOUR_USERNAME printer-name-42

Encryption protects the connection in transit, not permission to cancel the job. Use your server's documented certificate and authentication setup, and never place passwords in shell history or invent an option for supplying one on the command line.

Leave -x out unless you specifically need to purge the job data files:

$ cancel -x printer-name-42

Normal cancellation stops the job without that extra deletion. With -x, recovery may be impossible if the document exists only in the spool, so preserve the original and resubmit it rather than treating spool data as a backup.

7. Diagnose a failed cancellation

Run the read-only queue check again and compare the exact destination and job ID. A missing job may have completed, been cancelled by someone else, moved queues, or gone to a different CUPS server entirely. If the scheduler is unavailable, verify the service and the remote host through your normal administration process.

If the server rejects the request, record the command with no password, the job ID, the server name and the error text. Ask the CUPS administrator about Cancel-Jobs authorisation in cupsd.conf. Do not reach for sudo automatically: CUPS permissions and authentication are server policy, and running the client as root will not repair a missing queue or a wrong remote host.

Checkpoint

Run lpstat -o once more. The intended job should be gone, or the server should give you a clear reason it remains.

Done means

  • Client and version confirmed. You checked the installed cancel client and CUPS version.
  • Target identified. You knew the exact job, destination and owner before changing the queue.
  • Narrowest option used. A job ID targeted a single cancellation wherever possible.
  • Bulk treated as bulk. -a was used only as a queue-wide, service-disrupting action.
  • Data preserved. -x stayed out unless deleting spool data was an explicit requirement.
  • Result checked. The queue was checked after the request, with the original document kept if resubmission might be needed.