Réf. : Re: Réf. : Re:

Helge Blischke h.blischke at srz.de
Mon Mar 21 05:29:42 PST 2005


Antoine PICOLET wrote:
> 
> Antoine PICOLET wrote:
> >
> > Here are the traces (in debug level) in my error log.
> > They show that the file (an OS/2 BMP image) passes through the imagetops
> > filter and then to the socket backend (note the problem occured also
> with
> > the lpd backend); then, the imagetops filter crashes because it cannot
> > deal with the file format, but the backend exit value is 0; and,
> finally,
> > the CUPS scheduler performs as if the backend did crash and the filter
> > not, so it disables the printer but keeps the corrupted job...
> > Note that I use syslog for logging, so the lines may be in
> non-chronologic
> > order :
> >
> > ProcessIPPRequest(0x40303008[6]): operation_id = 0002
> > print_job(0x40303008[6], ipp://localhost:631/printers/printer1)
> > print_job: auto-typing file...
> > print_job: request file type is image/x-bitmap.
> > check_quotas(0x40303008[6], 0x81a4fe8[printer1])
> > check_quotas: requesting-user-name = 'root'
> > print_job: requesting-user-name = 'root'
> > Adding start banner page "none" to job 113.
> > copy_banner(0x40303008[6], 0x8139b18[113], none)
> > add_file(con=0x40303008[6], job=113, filetype=image/x-bitmap,
> > compression=0)
> > Adding end banner page "none" to job 113.
> > copy_banner(0x40303008[6], 0x8139b18[113], none)
> > Job 113 queued on 'printer1' by 'root'.
> > Job 113 hold_until = 0
> > SaveJob: Closing file 8...
> > StartJob(113, 0x81a4fe8)
> > StartJob() id = 113, file = 0/1
> > job-sheets=none,none
> > banner_page = 0
> > StartJob: argv =
> >
> "printer1","113","root","test-bmp-os2.bmp","1","","/var/spool/cups/d00113-001"
> > StartJob: envp[0]="PATH=/usr/lib/cups/filter:/bin:/usr/bin"
> > StartJob: envp[1]="SOFTWARE=CUPS/1.1"
> > StartJob: envp[2]="USER=root"
> > StartJob: envp[3]="CHARSET=iso-8859-1"
> > StartJob: envp[4]="LANG=en"
> > StartJob: envp[5]="TZ=UTC"
> > StartJob: envp[6]="PPD=/etc/cups/ppd/printer1.ppd"
> > StartJob: envp[7]="CUPS_SERVERROOT=/etc/cups"
> > StartJob: envp[8]="RIP_MAX_CACHE=8m"
> > StartJob: envp[9]="TMPDIR=/var/spool/cups/tmp"
> > StartJob: envp[10]="CONTENT_TYPE=image/x-bitmap"
> > StartJob: envp[11]="DEVICE_URI=socket://i915.prn.msy.sagem:9100"
> > StartJob: envp[12]="PRINTER=printer1"
> > StartJob: envp[13]="CUPS_DATADIR=/usr/share/cups"
> > StartJob: envp[14]="CUPS_FONTPATH=/usr/share/cups/fonts"
> > StartJob: Allocating status buffer...
> > StartJob: statusfds = [ 8 9 ]
> > StartJob: filterfds[1] = [ 10 -1 ]
> > StartJob: filter = "/usr/lib/cups/filter/imagetops"
> > StartJob: filterfds[0] = [ 11 12 ]
> > start_process("/usr/lib/cups/filter/imagetops", 0xbffef530, 0xbffee8a0,
> > 10, 12, 9)
> > PID 17886 stopped with status 1!
> > Started filter /usr/lib/cups/filter/imagetops (PID -17886) for job 113.
> > StartJob: backend = "/usr/lib/cups/backend/socket"
> > StartJob: filterfds[1] = [ -1 10 ]
> > start_process("/usr/lib/cups/backend/socket", 0xbffef530, 0xbffee8a0,
> 11,
> > 10, 9)
> > Started backend /usr/lib/cups/backend/socket (PID 17887) for job 113.
> > StartJob: Adding fd 8 to InputSet...
> > add_job_state_reasons(0x40303008[6], 113)
> > ProcessIPPRequest: 6 status_code=0
> > ProcessIPPRequest: Adding fd 6 to OutputSet...
> > [Job 113] printer1 113 root test-bmp-os2.bmp 1
> /var/spool/cups/d00113-001
> > [Job 113] ImageOpen("/var/spool/cups/d00113-001", 1, 1, 100, 0, (nil))
> > [Job 113] offset = 26
> > [Job 113] Bad BMP dimensions 102500389x1572865x8251
> > [Job 113] Unable to open image file for printing!
> > PID 17887 exited with no errors.
> > [Job 113] Attempting to connect to host i915.prn.msy.sagem on port 9100
> > [Job 113] Connected to host, sending print job...
> > [Job 113] Print file sent, waiting for printer to finish...
> > [Job 113] Ready to print.
> > UpdateJob: job 113, file 0 is complete.
> > UpdateJob: Removing fd 8 from InputSet...
> > StopJob: id = 113, force = 0
> > Saving printers.conf...
> > StopJob: printer state is 5
> > StopJob: Freeing status buffer...
> > SaveJob: Closing file 8...
> > WriteClient: Removing fd 6 from OutputSet...
> > ReadClient() 6, used=0
> > CloseClient() 6
> > CloseClient: Removing fd 6 from InputSet and OutputSet...
> >
> > Helge Blischke <h.blischke at srz.de>
> >
> > Envoyé par : cups-bounces at easysw.com
> > 18/03/2005 13:07
> > Veuillez répondre à "Mirror of cups.general Newsgroup"
> > Remis le : 18/03/2005 13:10
> >
> >
> >         Pour :  cups at easysw.com
> >         cc :    (ccc : Antoine PICOLET/DRD/SAGEM)
> >         Objet : Re: [cups.general] Printer queue gets closed when print
> file is
> >
> > Antoine PICOLET wrote:
> > >
> > > Hello,
> > >
> > > I am currently using CUPS 1.1.19, on a Linux SuSE Linux Entreprise
> > Server
> > > 8.0. I do use a lot of different printers, generally using lpd and
> > socket
> > > backends.
> > >
> > > I supppose that, when I send to print a file which will make a filter
> > fail
> > > (typically, an OS/2 BMP - by the way, is this normal ?, or some PDF
> > > files), the job is removed by the scheduler, and gets an 'aborted'
> > status,
> > > and the printer queue itself is left unchanged. However, in my case,
> the
> > > printer queue gets closed, and the job remains; as soon as I reopen
> the
> > > queue (by 'enable'), the job tries to print again and the queue
> > > immediately gets closed again. I have to remove the job before I can
> > > reopen the queue.
> > > Note that this does not happen with files in an unsupported format
> > > (application/msword...) since they are immediately refused by the
> > server.
> > >
> > > I know I am using an old version of CUPS. I tried version 1.1.23, and
> > the
> > > problem does not seem to occur anymore, however it did not occur each
> > time
> > > with 1.1.19, and,I cannot find it in the list of bugs corrected
> between
> > > 1.1.19 and 1.1.23. Has this behavior been specifically corrected ?
> Does
> > > anyone have seen this kind of problem (in any version of CUPS), or
> know
> > > what kind of misconfiguration might be causing it ?
> > >
> > > Thank you in advance .
> > >
> > > Antoine
> >
> > You should look into the error_log and see which filter(s)/backend(s)
> > are
> > said to have exited with a status > 0.
> >
> > Helge
> >
> >
> 
> > Well, if you carefully look at your log, you'll find that the imagetops
> > filter
> > has been started and the PId 17886 assigned.
> > And the log tells you that the PID 17886 (i.e. just this filter) stopped
> > with status 1. Thus, the scheduler puts the queue into the stop state.
> 
> > Helge
> 
> Well, this is exactly what I am saying... the logs say that the backend is
> OK,
> and the filter is not because the print data is corrupted. In this case, I
> 
> believe CUPS is not supposed to put the queue in stop state - which it
> would
> have had to do if the backend had had an error - but rather abort the job
> itself, giving it an "aborted" status !
> Doing it the way it does (ie, stopping the print queue when a corrupted
> job arrives) means that anybody can close a print queue by sending some
> weird
> data, and that it then takes an administrator to cancel the job and reopen
> the print queue.
> 


Which version of CUPS are you using? In the past, there may have been
issues
with backends being killed by SIGTERM and this being treated as a
backend failure.

Perhaps you could post an URL to your sample file for me (or anybody
else)
to test?

Helge

-- 
Helge Blischke
Softwareentwicklung
SRZ Berlin | Firmengruppe besscom
http://www.srz.de




More information about the cups mailing list