Loading...

VONDS ©

Lab 138: Printing & Mail Queue Workflow

Back to Lab Index

Validate printing and outbound mail on a RHEL host by verifying CUPS, submitting a test job, and confirming queue state. Triage the Postfix mail queue by forcing delivery, removing a stuck message by ID, and capturing the timeline in unit logs.

troubleshooting mail core

Scenario

A helpdesk ticket reports printing is “working sometimes,” and outbound mail is backing up. You need to validate the print service, submit a known-good test job, confirm it appears in the queue, then triage Postfix by inspecting the mail queue, forcing a delivery attempt, deleting a stuck message, and capturing evidence from the journal.

Operator context

Your goal is fast proof. Confirm services are healthy, generate a controlled test event (print job, queue flush), then validate the system recorded the result in unit logs.

Objective

  • Confirm the CUPS scheduler is active.
  • Identify printers and the default destination.
  • Submit a test print job and validate it appears in the queue.
  • Confirm Postfix is active.
  • Inspect the mail queue and identify deferred/stuck entries.
  • Flush the queue to force a delivery attempt.
  • Delete a specific stuck message by queue ID.
  • Confirm the queue state after remediation.
  • Capture evidence with unit logs from journald.

Concepts

  • Service verification and quick health checks using systemctl.
  • CUPS workflows: destinations, job submission, and queue inspection (lpstat, lp, lpq).
  • Postfix queue triage: viewing queue state and deferral reasons (mailq, postqueue -p).
  • Controlled remediation: forcing delivery attempts and deleting a specific entry (postqueue -f, postsuper -d).
  • Evidence collection using unit logs (journalctl -u).

Walkthrough

Step 1: Verify the CUPS service is running.
Command 
sudo systemctl status cups --no-pager

Confirm cups is active. If it is down, printing will be intermittent or fail entirely. 

● cups.service - CUPS Scheduler
Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; preset: enabled)
Active: active (running) since Sun 2026-01-25 06:41:12 EST; 31min ago
Main PID: 1126 (cupsd)
Step 2: List printers and identify the default destination.
Command 
lpstat -p -d

You want to see at least one printer and a default destination. This determines where test jobs go. 

printer Office_Printer is idle. enabled since Sun 25 Jan 2026 06:41:14 AM EST
system default destination: Office_Printer
Step 3: Submit a test job to the default printer.
Command 
lp /etc/hosts

Creating a fresh job gives you a known-good signal to watch through the queue. 

request id is Office_Printer-23 (1 file(s))
Step 4: Confirm the print queue shows the job.
Command 
lpq

You are looking for the job ID and state. If jobs pile up or remain active too long, validate printer connectivity and backend filters next. 

Office_Printer is ready
Rank   Owner   Job  File(s)                         Total Size
active lab     23   hosts                           1024 bytes
Step 5: Verify Postfix is running.
Command 
systemctl is-active postfix

If Postfix is inactive, mail will not move and the queue will grow quickly. 

active
Step 6: Inspect the Postfix mail queue.
Command 
mailq

Identify deferred entries and record the reason string. In this scenario, one message is stuck due to a connection timeout to the upstream MX on port 25. 

-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2C61A012*     1468 Sun Jan 25 07:06:11  alerts@example.com
                                         ops@example.com
                                         (connect to mx.example.com[203.0.113.25]:25: Connection timed out)
1F9B77C0A9       912 Sun Jan 25 07:07:04  root@lab138
                                         admin@example.com
-- 2 Kbytes in 2 Requests.
Step 7: Force a delivery attempt.
Command 
postqueue -f

Flushing the queue is a fast way to validate whether the failure persists right now.

Step 8: Delete the stuck message by queue ID.
Command 
sudo postsuper -d 3F2C61A012

This removes a specific entry. In real incidents, document why you deleted it and capture the failure reason first. 

postsuper: Deleted: 1 message
Step 9: Re-check the queue to confirm the deletion.
Command 
postqueue -p

Confirm the stuck message is gone and the queue is smaller. 

-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
1F9B77C0A9       912 Sun Jan 25 07:07:04  root@lab138
                                         admin@example.com
-- 1 Kbytes in 1 Request.
Step 10: Capture evidence in the journal for Postfix activity.
Command 
journalctl -u postfix -n 8 --no-pager

Unit logs provide the incident timeline: enqueue, delivery attempts, deferral reason, flush, and deletion. 

Jan 25 07:06:11 lab138 postfix/qmgr[1288]: 3F2C61A012: from=, size=1468, nrcpt=1 (queue active)
Jan 25 07:06:44 lab138 postfix/smtp[1410]: 3F2C61A012: to=, relay=mx.example.com[203.0.113.25]:25, delay=33, dsn=4.4.1, status=deferred (connect to mx.example.com[203.0.113.25]:25: Connection timed out)
Jan 25 07:12:20 lab138 postfix/postqueue[1467]: warning: flush request received
Jan 25 07:12:30 lab138 postfix/postsuper[1481]: Deleted: 3F2C61A012
Jan 25 07:12:31 lab138 postfix/qmgr[1288]: 3F2C61A012: removed

Common breakpoints

No printers listed

If lpstat -p -d shows no destinations, confirm printer configuration exists and that CUPS is reachable. If this is a remote print server workflow, validate connectivity and name resolution.

Jobs remain active or stuck in the print queue

If lpq shows the same job for an extended time, check printer connectivity, backend filters, and CUPS logs. Confirm the destination is enabled and accepting jobs.

mailq shows repeated deferrals

Deferrals usually indicate a network path or policy problem. Confirm DNS for the relay target, firewall rules, and that outbound SMTP is permitted from this host.

postqueue -f does not change queue size

A flush only triggers retries. If the upstream is still unreachable, you will see the same deferral reason again. Use unit logs to capture the current failure evidence.

Cleanup checklist

This lab is read-only except for the test print job and mail queue actions. If you deleted a message, capture the queue ID and deferral reason in your incident notes before closing the ticket.

Commands 
lpstat -p -d
lpq
postqueue -p
journalctl -u postfix -n 15 --no-pager
Success signal

Print jobs enter the expected destination queue, and the mail queue reflects your remediation actions with a clear timeline in unit logs.

Reference

  • systemctl status cups --no-pager : Verify the print scheduler is active and inspect recent unit output.
    • --no-pager: Prints output without paging.
  • lpstat -p -d : List printers and show the default destination.
    • -p: Lists printers and their enabled/disabled state.
    • -d: Shows the default destination.
  • lp <file> : Submit a print job to the default destination.
    • /etc/hosts: Small, safe test file for a controlled print job.
  • lpq : Show the current print queue for the default destination.
  • systemctl is-active postfix : Confirm the mail service is running.
  • mailq : View the Postfix queue and deferral reasons.
  • postqueue -p : Display queued messages and their status.
    • -p: Prints the mail queue.
  • postqueue -f : Flush the queue to force a delivery attempt.
    • -f: Requests immediate retry of queued mail.
  • postsuper -d <QUEUEID> : Delete a specific message from the queue.
    • -d: Deletes the message by queue ID.
  • journalctl -u postfix -n <N> --no-pager : View Postfix unit logs for timeline and evidence.
    • -u postfix: Filters logs to the Postfix unit.
    • -n <N>: Limits to the last N entries.
    • --no-pager: Prints output without paging.