lpmove

[John A. Murdie]

On Nov 30, 2005, in message cups.general:23230, Helge Blischke wrote:
> lpmove will probably fail if the job to be moved is marked as
> "processing". Try to put the job in question
> into hold, move then, and release the job again.
>
> Helge

Can someone confirm that a 'Processing' job can't successfully be moved - Helge, Mike? The web interface 'Hold job' button only appears when a job is not 'Processing', however. (Moving a held job doesn't release it to the new printer, of course.)

Both the web interface and lpmove(1) work as advertised when I move a 'Pending' or 'Held' job. (This is with CUPS 1.2.8 on Solaris with a Linux client, with the socket backend unwrapped by accsnmp or anything similar.) When the job is 'Processing', however, both move commands appear to work but have no effect. I'm surprised that I don't get an error message either from the lpmove(1) command or from the web interface - perhaps client-error-not-possible. The FAQ mentions one cause of client-error-not-possible:

8. Trying to move a job that has already printed.

There's no discussion of the web 'Move Job' button on the web interface's 'CUPS Help Pages', and the manual page for lpmove(1) doesn't explain what happens when the backend is already in receipt of the job data - one might expect that the scheduler would send the backend a SIGKILL and that the job would be restarted on the new printer. (The CUPS book predates lpmove(1) and web-interface 'Move job' button, of course, so no discussion there.) Is this what is meant to happen (eventually?), or not?

Perhaps this is functionality Mike intends to add in the future. (I can't find any RFE or the roadmap - http://www.cups.org/roadmap.php - about 'Move Job', though.) Mike, you're doing a fantastic job on CUPS - it's a far more complex task than I'd ever like to take on now. I only hope that the contributions, RFEs and problem reports you are getting from having made it free source is worth the hassle you get from the same quarter!

John A. Murdie