On Tue, Mar 6, 2012 at 2:46 PM, Nils Philippsen <nils(a)redhat.com> wrote:
On Mon, 2012-03-05 at 12:02 -0500, Bill Nottingham wrote:
> Tim Waugh (twaugh(a)redhat.com) said:
> > For things like cloud printing, where the print server is a hosted
> > service somewhere out in the Internet, I think the applications should
> > be talking directly to it (via the print dialog).
> >
> > For a plain network printer, where the printer might not be able to
> > accept the job while it's busy processing others, you might have to
> > queue the job and retry it later. So if you are doing that as a user
> > process, how should that work when you log out, and when the machine is
> > restarted?
>
> It waits until you log in again.
I wonder if that works with longer print jobs:
- User: "I'll kick that one off before the weekend, it might take a
while, so that I won't disturb others."
- (User's) cupsd: queues the job in user's home, starts printing onto
the printer.
- User logs off after 15 pages of 300 are printed.
- systemd kills off all processes in user session cgroup, including
cupsd.
- User: "Aiiieh!", heads off into the weekend as he has to catch a bus,
forgets about it.
- User returns after the weekend, logs in again, cupsd picks up the
still queued print job from user's home, starts printing the remaining
285 pages.
This requires:
* A network printer
* ... that has a 300page paper tray, so it is clearly an industrial one
* ... but does not have a separate print queue
* an user that starts a print job and leaves?
I don't know how much that is likely.
In any case, the per-user cupsd could stay running after the user logs
off until the queue is empty - then there should be no discernible
difference between the system queue and per-user queue until the
system reboots (when it reboots, the per-user cupsd probably wouldn't
start and continue processing the job again - although that could be
arranged as well).
Mirek