[26338] in Athena Bugs
Re: sun4 9.3.18: Athena Printing
daemon@ATHENA.MIT.EDU (Roger A. Roach)
Thu Feb 3 09:18:49 2005
In-Reply-To: <200502030133.j131XhoF008701@red-herring.mit.edu>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <544c9dde2fd08e3b1ae6269724cbcd2f@mit.edu>
Content-Transfer-Encoding: 7bit
From: "Roger A. Roach" <rar@mit.edu>
Date: Thu, 3 Feb 2005 09:16:29 -0500
To: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
Camilla,
Thanks for the reply. It is not an urgent problem, but I wanted to
make sure it was reported in case it happens again. I probably was not
as clear as I should have been. I did try to print two files from my
home on Saturday. When I came in to pick them up on Sunday, there was
no printout on the printer. The printer was in the dimmed PowerSave
mode. (e.g. no error message). That is when I did the first lpr to
see if my request was stuck in the queue (a frequent problem for all of
our Athena printers in W91 I might add). Since the queue was empty
(with the indication that it had been printed the previous day), I
thought the only other possibility was that someone had been in on
Saturday and picked up my output by mistake.
I then printed the file again from my office Mac and got the immediate
in/out of the queue that my second lpr showed. When I went to the
printer, it was still in PowerSave mode. Thus I knew there was a
problem in the interaction with the printer and Athena Print Services.
I printed my file on another printer to insure it wasn't the file. It
printed OK on SST1. I then powercycled the printer (W91P) and tried to
print, this time successfully. Thus my assumption of a problem
communicating between Athena Print Services and the printer.
Regarding your suggestions.
This was not a PDF file. It was a print of some mail via the Apple
Mail application using the "HP Color LaserJet 5500 v3010.107" driver
(IP printing). This is the same on my home Mac and my office Mac.
This same file printed out successfully on both printers later, so I
assume this is not a bad PostScript problem. I still have the mail
files if you are interested, but I don't think they will help.
The possibility of an interaction with PowerSave mode seems more
likely. However, I would guess that a printer has to acknowledge that
it is ready to receive a file and acknowledge at least the successful
reception of the file before APS removes the request from the queue.
Would a printer do this in PowerSave mode?
Based on this and my other problem of files frequently getting stalled
until I power cycle the printer, I am guessing that the handshaking
between APS and the printers is not as robust as it might be. That
would be my guess rather than an application error. I know it is not
easy to debug and may not even be worth trying unless other people
report similar problems.
Thanks and good luck.
Roger
On Feb 2, 2005, at 8:33 PM, Camilla R Fox wrote:
>
> Sorry about the delay in getting back to you on this one; it got buried
> behind the usual pile of Monday email.
>
> I don't think I have quite enough information to figure out what
> happened, but I did look up the accounting logs on the print server, to
> find the jobs that correspond to the jobs cited here. (I've quoted the
> full logs but they're a little hairy, so I'll try to interpret.)
>
>> rar.mit.edu(8:46am)% lpq -P W91C
>> Printer: w91c@arbor-eater 'HP4500C W91-230'
>> Queue: no printable jobs in queue
>> Status: job 'rar@Roach-PBG4+905' removed at 15:52:08.749
>> Filter_status: done at 15:52:08.729
>
> It looks like this lpq was run before any jobs were sent to the print
> server, first thing Monday morning. The 15:52 timestamp is for a job
> printed on Saturday afternoon.
>
> jobstart -HRoach-PBG4.local -nrar -Pw91c -kcfA905Roach-PBG4.local
> -b989164 -t2005-01-29-13:12:02.000
> start -q15620 -p80361 -t2005-01-29-13:12:04.080 -Arar@Roach-PBG4+905
> -Fl -HRoach -PBG4.local -JKim Komando Show Electronic Newsletter --
> January 29, 2005 -Pw91c -QW91C -a/var/spool/printer/w91c/w91c-acct
> -d/var/spool/printer/w91c -edfA905Roach-PBG4.local -fKim Komando Show
> Electronic Newsletter -- January 29, 2005 -hRoach-PBG4.local -j905
> -kcfA905Roach-PBG4.local -l66 -nrar -sstatus -w80 -x0 -y0
> /var/spool/printer/w91c/w91c-acct
> end -b0 -T9606 -q15620 -p80361 -t2005-01-29-15:52:08.728
> -Arar@Roach-PBG4+905 -Fl -HRoach-PBG4.local -JKim Komando Show
> Electronic Newsletter -- January 29, 2005 -Pw91c -QW91C
> -a/var/spool/printer/w91c/w91c-acct -d/var/spool/printer/w91c -e
> dfA905Roach-PBG4.local -fKim Komando Show Electronic Newsletter --
> January 29, 2005 -hRoach-PBG4.local -j905 -kcfA905Roach-PBG4.local
> -l66 -nrar -sstatus -w80 -x0 -y0 /var/spool/printer/w91c/w91c-acct
> jobend -HRoach-PBG4.local -nrar -Pw91c -kcfA905Roach-PBG4.local
> -b989164 -t2005-01-29-15:52:08.000
>
> The '-p80361' here is the hardware page count, and the fact that it
> doesn't change between the "start" and "end" logs does indicate a
> problem. Also indicating the problem, we have the job starting at
> 13:12
> and ending at 15:52.
>
>> rar.mit.edu(8:56am)% lpq -P W91C
>> Printer: w91c@arbor-eater 'HP4500C W91-230'
>> Queue: no printable jobs in queue
>> Status: job 'rar@RARPB+32' removed at 08:57:21.658
>> Filter_status: done at 08:57:21.639
>
> jobstart -HRARPB.MIT.EDU -nrar -Pw91c -kcfA032RARPB.MIT.EDU -b214982
> -t2005-01-31-08:57:17.000
> start -q19925 -p80362 -t2005-01-31-08:57:19.166 -Arar@RARPB+32 -Fl
> -HRARPB.MIT.EDU -JYour weekly Gartner alerts for the week ending 30
> January 2005 -Pw91c -QW91C -a/var/spool/printer/w91c/w91c-acct
> -d/var/spool/printer/w91c -edfA032RARPB.MIT.EDU -fYour weekly Gartner
> alerts for the week ending 30 January 2005 -hRARPB.MIT.EDU -j032
> -kcfA032RARPB.MIT.EDU -l66 -nrar -sstatus -w80 -x0 -y0
> /var/spool/printer/w91c/w91c-acct
> end -b0 -T4 -q19925 -p80362 -t2005-01-31-08:57:21.638 -Arar@RARPB+32
> -Fl -HRARPB.MIT.EDU -JYour weekly Gartner alerts for the week ending
> 30 January 2005 -Pw91c -QW91C -a/var/spool/printer/w91c/w91c-acct
> -d/var/spool/printer/w91c -edfA032RARPB.MIT.EDU -fYour weekly Gartner
> alerts for the week ending 30 January 2005 -hRARPB.MIT.EDU -j032
> -kcfA032RARPB.MIT.EDU -l66 -nrar -sstatus -w80 -x0 -y0
> /var/spool/printer/w91c/w91c-acct
> jobend -HRARPB.MIT.EDU -nrar -Pw91c -kcfA032RARPB.MIT.EDU -b214982
> -t2005-01-31-08:57:21.000
>
> This job seems to start and end almost at the same time; no sitting
> there for hours, but also no increment to the page count (though one
> page between the previous log and now, which may be a header page).
>
> In each case, the "end" log indicates that the printer eventually
> returned a successful status. A type of job I'd expect to see cause
> this kind of behavior is one whose postscript source is malformed,
> perhaps lacking a showpage.
>
> Things you can check:
>
> * If this is a PDF document, printed from acroread, make sure that
> "language level 2" is selected in the bottom right area of the
> print
> dialogue box.
>
> * If this was given to you as a PostScript or EPS file, and it views
> acceptably with 'gs' or 'gv' you might have luck using a utility
> such
> as 'ps2ps' to rewrite it (this will use the ghostscript engine to
> interpret the file, then write out postscript from the result).
>
> (It's also known that some PDF documents produce "bad" PostScript
> when converted with the usual tools; printing to PostScript from
> Acroread, then handling the document as a bad PostScript document
> can be appropriate.)
>
> * PostScript that's been generated on windows often comes out best if
> you can use the Apple LaserWriter PostScript driver, rather than
> one
> that's specific to a particular model of HP.
>
> It would also be helpful to know what the panel of the printer
> indicated
> while it was working on the job on Saturday afternoon; a job producing
> no output quickly like Monday morning's, coupled with the printer being
> stuck in power saving mode until poked, would be plausible, as would a
> job that sucked down memory on the printer until the printer gave up.
>
> Otherwise, we're often stuck blaming the application that created
> the document (and the document itself). If you want me to examine a
> particular example, do let me know.
>
> Camilla Fox
> IS&T Server Operations
