[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#860591: cups-daemon: Job enters queue, then stops and can't be removed



On Thu 20 Apr 2017 at 09:19:49 +1000, Ben Finney wrote:

> $ sudo systemctl status cups
> ● cups.service - CUPS Scheduler
>    Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
>    Active: failed (Result: exit-code) since Thu 2017-04-20 09:14:08 AEST; 20s ago
>      Docs: man:cupsd(8)
>   Process: 15217 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE)
>  Main PID: 15217 (code=exited, status=1/FAILURE)
>       CPU: 44ms
> 
> Apr 20 09:13:47 lantana systemd[1]: Started CUPS Scheduler.
> Apr 20 09:14:08 lantana systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE
> Apr 20 09:14:08 lantana systemd[1]: cups.service: Unit entered failed state.
> Apr 20 09:14:08 lantana systemd[1]: cups.service: Failed with result 'exit-code'.
> 
> $ ls /home/bignose/testq*
> ls: cannot access '/home/bignose/testq*': No such file or directory
> 
> =====
> 
> I am attaching the resulting ‘/var/log/cups/error_log’ to this message.

Thank you for this and all the other detail.

> I [20/Apr/2017:09:14:08 +1000] [Client 12] Installing config file "/etc/cups/cupsd.conf"...
> D [20/Apr/2017:09:14:08 +1000] [Client 12] cupsdSendHeader: code=201, type="(null)", auth_type=0
> D [20/Apr/2017:09:14:08 +1000] cupsdSetBusyState: newbusy="Dirty files", busy="Active clients and dirty files"
> D [20/Apr/2017:09:14:08 +1000] [Client 12] Closing connection.
> D [20/Apr/2017:09:14:08 +1000] cupsdSetBusyState: newbusy="Dirty files", busy="Dirty files"
> E [20/Apr/2017:09:14:08 +1000] Scheduler shutting down due to program error.

The scheduler crashes. The job gets nowhere near the filtering system.
The symptoms you have described in your first mail could have been
caused by a fault there or (unlikely because the two printers are
connected differently) a backend. This rules those possibilities out.

This is a relatively recent change in behaviour. Could it be CUPS issue
#4915?

  https://github.com/apple/cups/issues/4915

Two things to try:

1. Do 'cupsctl debuglevel=warn' and 'systemctl status cups'. cups crashes
   for me on the first command.

2. Upgrade experimental to the present cups 2.2.3-1. The changelog has

     * Cherry-pick upstream fix for regression in job file preservation

   Set up testq again and test for a file in $HOME. Do some printing to
   both printers.

Thanks,

-- 
Brian.


Reply to: