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

Bug#354581: marked as done (cupsys - networked printing hangup because spool limit reached)

Your message dated Sun, 1 Jun 2008 23:09:06 +0200
with message-id <20080601210906.GB6509@piware.de>
and subject line Cleaning up old bug reports
has caused the Debian Bug report #354581,
regarding cupsys - networked printing hangup because spool limit reached
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
354581: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354581
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: cupsys
Version: 1.1.23-10sarge1

Problem:
I got Samsung printer connected using USB on host Zivotne1, and I got it net-connected using CUPS on Zivotne2 too. Zivotne1 is CUPS server in this order, and Zivotne2 is client.
Suddenly, after some time, Zivotne2 printing stopped. The CUPS only offered some not very thankful error and switched the network printer off. From /var/log/cups on client and on server I got only strange "no file ?!?" errors.
The Zivotne1 has set MaxJobs 500 and spool/cups contained 499 files. This was first suspicion for me. However, the local printing on Zivotne1 (the CUPS server) worked well. 
I must have
1, delete the spool on server
2, cancel all jobs on client
3, started the printer on client
and afther all of that, the new print jobs started working.
Seems to me, that local jobs have no problem of cycling the jobs files, whereas the network jobs cannot. The client sends the job to server, however couldn't send the file. Server notices the job, however dosen't have the file-to-print for that job, so ends up with error. I assume the client goes to some kind of deadlock then, because i see that printing HAVEN'T started even after cleaning up the spool/cups on server, even after starting the printer manually. Only effectively way out of the client's deadlock has been cancelling of all print jobs on client.

--- End Message ---
--- Begin Message --- 
Dear bug submitter,

This bug was reported against a very old version of cups (older than
in the current stable Debian version "Etch"). About a year ago,
Martin-Eric Racine asked for feedback whether the bug still applied to
the current Debian Etch version, but we did not get any feedback. In
order to not keep around old, hardware-specific, and inactive bugs
around forever, I close this bug now.

Please report back if you still experience the problem with the
current version in Etch; if you can test Lenny/unstable, that would be
highly appreciated, of course. I will reopen this bug then.

Thank you for your report!

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: