Ticket #504 (closed task: invalid)

Opened 14 years ago

Last modified 14 years ago

investigate sporadic reports of disappearing jobs

Reported by: geofft Owned by:
Priority: low Milestone: Summer 2010 (Lucid Deploy)
Component: printing Keywords:
Cc: Fixed in version:
Upstream bug:


A couple of people have mentioned to me that they print jobs and they disappear into the ether. Sometimes they get header pages and no job (I'm not sure if this is a related issue). Do we have a way to track this sort of thing?

Change History

comment:1 Changed 14 years ago by kaduk

I had this happen to me this afternoon (printing from a genuine BSD lpr client on my desktop to celine on get-print).
That is, no output and no header page, either.

My job showed up in cups-lpq output from a cluster box, but when it reached the top of the
queue, both it and the only job after it disappeared from the queue, and did not print.
Mark looked at the logs on get-print, but only saw evidence of my second attempt to print my job.

   Zephyr from mmanley  15:24  (Mark W. Manley)
       I honestly don't see anything that suggests it lost a job.  I know that around
       2:59 the queue hoover that I wrote ran that boots jobs over a day old, but
       there isn't anything to suggest it stomped on any other jobs
   Zephyr sent to mmanley  15:24  (very subtle joke)
   Zephyr from mmanley  15:25  (Mark W. Manley)
       I'll keep checking.  The problem is that when users submit jobs through LPD,
       the logging that cups does is minimal.
   Zephyr from mmanley  15:25  (Mark W. Manley)
       Or more minimal, I should say

Has anyone seen this happen when they used a CUPS lpr client to submit the job?

comment:2 Changed 14 years ago by geofft

One of my dormmates reports that she printed a job from evince in a cluster today, and it didn't show up in lpq although jobs ahead of and behind hers did, but yet her job printed in the order it ought to have. What.

comment:3 Changed 14 years ago by jdreed

  • Milestone set to Summer 2010 (Lucid Deploy)

This may have been the cause of one of the problems (from 4/8):

debathena / cups / mmanley 14:12 (My eyes! These goggles do nothing!)

If the printer accounting filter encountered a printer with SNMP
errors in the management interface, it would freak and throw your
job away without so much as an error.

debathena / cups / mmanley 14:12 (My eyes! These goggles do nothing!)

That's cleared up now, I believe.

Additionally, I suspect that the jobs are not actually disappearing, but are taking ~forever to get from the local cupsd to our servers. We don't know what causes this.

If we don't hear future reports, we should close this.

comment:4 Changed 14 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to invalid

We need some real data on this, and with the likely impending change to printing, I'm closing this.

Note: See TracTickets for help on using tickets.