CUPS disables the queue when backend returns exit code 3

[michaelrsweet]

Version: 1.2rc3
CUPS.org User: kurtbcox

From the backend man page, I assumed that CUPS should hold the job but not disable the queue.

I am writing a backend in python that allows one to print to pdf format and the resulting pdf is emailed to the user.

If the user submitted an unreachable email address then the backend should handle the exception and do a "sys.exit(3)". CUPS however disables the queue instead of simply holding the job.

[michaelrsweet]

CUPS.org User: pipitas

Is this for CUPS 1.1.x or 1.2 (soon to be released)?

The man page here is already describing the 1.2 behaviour:

http://www.cups.org/documentation.php/man-backend.html

I believe the behaviour for backend handling by the scheduler based on different exit codes is not yet enabled in 1.1.x.

[michaelrsweet]

CUPS.org User: mike

Yeah, what Kurt said...

If you are using CUPS 1.2, then we'll need to see the error_log file with the LogLevel set to "debug".

[michaelrsweet]

CUPS.org User: kurtbcox

Indeed, it is cups 1.2rc3.

I posted an extract from the error_log file showing when Job 98 is started up until it is eventually removed from the queue by the user.

CUPS receives exit status 3 from the backend but the queue is still stopped instead of just putting the job on hold.

[michaelrsweet]

CUPS.org User: mike

OK, can you test the current trunk code and let me know if the problem persists?

(and if it does, attach a snippet of your error_log file with the job messages...)

Thanks!

[michaelrsweet]

CUPS.org User: kurtbcox

Ok, I compile the current svn revision 5486.

I get the same error, so I spent an extra day checking if maybe the backend doesn't exit cleanly

See the attached Job125_error.log which shows the sequence for job 125.
Please note the attached backend smtp_v2

[michaelrsweet]

CUPS.org User: mike

OK, looks like the exit code is not getting decoded properly - 768 instead of 3. Looking into it...

[michaelrsweet]

CUPS.org User: mike

OK, I think we have a winner now - the exit status was stored as-is by the scheduler main loop for the job handler to process, but we didn't check for termination by a signal. The new code properly decodes the exit status and should work perfectly now.

Please let me know how things go...