Date: Wed, 05 Mar 2014 22:52:43 -0700 From: Gary Aitken <freebsd@dreamchaser.org> To: Polytropon <freebsd@edvax.de> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: printer woes Message-ID: <53180D2B.9000509@dreamchaser.org> In-Reply-To: <20140306023944.707250df.freebsd@edvax.de> References: <5317C0E7.5010105@dreamchaser.org> <20140306023944.707250df.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/05/14 18:39, Polytropon wrote:
> On Wed, 05 Mar 2014 17:27:19 -0700, Gary Aitken wrote:
>> When I try to print something from gimp using gutenprint,
>> it generates the print data and control files in the spool directory
>> (cf..., df...)
>> However, the printer never wakes up and does anything.
>> lpd is running, and the lock file indicates the pid of one of the lpd processes
>> There is an errs.xxxxxx file which is empty (how is this used??)
>> status file has a message from when I set it and it never seems to change
>>
>> Any ideas why the lpd process isn't doing anything?
>>
>> cups is installed and cupsd is running,
>> although it's my understanding gutenprint from gimp bypasses cups;
>> nothing shows up in the cups queues, no surprise there.
>
> As far as I understand the (quite complicated) relationships
> of the many components of "modern" printing (CUPS, gutenprint,
> foomatic, hpijs, zjs and who knows what), printing from Gimp
> will write to the "CUPS standard input", so CUPS is not
> entirely bypassed -- it _cannot_, because it became the
> printing handler (printer filters and spoolers).
It would be nice to know how it's "supposed" to work...
Cups installs its own version of lp, lpr, lpstat, lpq...
However, the gimp gutenprint dialog simply uses "lp" as the command,
and not /usr/local/bin/lp.
So that would use /usr/bin/lp, which would bypass cups,
but require /usr/sbin/lpd.
>> The gutenprint dialog shows three printers:
>> Printer
>> HP 8500
>> epson3880
>> Attempting to print to the hp or epson fails;
>> printing to Printer prints fine to the hp8500,
>> which is the first printer listed in /etc/printcap
>
> I don't think CUPS uses /etc/printcap. The system's printer
> subsystem (lpd) does.
ok, will keep that in mind.
>> epson attempts leave the cf and df files in the printer's spool directory,
>> with no errors listed in /var/log/lpd-errs
>
> You also don't get mail from CUPS? It usually addresses root,
> or any other user if you have an /etc/mail/aliases "redirect",
> in case of errors.
In the case of the hp attempts I got mail from cups;
nothing for the epson attempts, which seem to hang in the middle
of processing the file.
>> hp attempts leave no cf or df files in the printer's spool directory,
>> and the following lines show up in the printer-specific error log:
>> GPL Ghostscript 9.06: Unrecoverable error, exit code 1
>> (repeated 5 times)
>
> This seems to indicate that the "translation" from PS (the
> format in which any _program_ sends printer output to whoever
> keeps the queues running) to the required printer-specific
> format (can be PCL or whatever the printer wants).
What seems strange is that I only get these messages for the hp;
when I send stuff to the epson, I get no messages.
>> and the following in /var/log/lpd-errs:
>> Mar 5 17:10:30 breakaway lpd[19654]: lp: lost connection
>> Mar 5 17:10:30 breakaway lpd[19654]: restarting lp
>> (repeat previous two 3 more times)
>
> This shows you're running system's lpd. You're _also_ running
> CUPS?
Yes. At least I was. I've killed off the system's lpd for now.
>> Mar 5 17:10:30 breakaway lpd[19654]: lp: lost connection
>> Mar 5 17:10:30 breakaway lpd[19654]: lp: job could not be sent to remote
>> host (cfA514breakaway.dreamchaser.org)
>
> This is the interesting part. You could try to start some tests
> from here:
>
> 1. Can you ping the printer? Does the name resolve correctly?
yes
> 2. Can you use nc (netcat) to send the data directly to the
> printer, _not_ using any system queue?
no, but I'm not sure exactly how to do this.
If I try
nc printer.ip.addr.here 9100 <file.ps
It just sits there, and the printer doesn't wake up.
>> Mar 5 17:10:30 breakaway lpd[19654]: mail sent to user garya about job
>> <unknown> on printer lp (FATALERR)
>
> Does the mail message contain any further details?
no
>> Print commands in the gutenprint dialog are as follows:
>> Printer lp -s
>> Printer Queue:(Default Printer)
>> HP 8500 lp -s -d 'HP_Officejet_Pro_8500_A909g' -oraw
>> Printer Queue:HP_Officejet_Pro_8500_A909g
>> epson3880 lp -s -d 'Epson_Stylus_Pro_3880' -oraw
>> Printer Queue:Epson_Stylus_Pro_3880
>>
>> If I select the hp or epson printer and set its print cmds and que to
>> match those of "Printer", I still get errors and no output.
>
> The last two commands expect gutenprint to provide the correct
> printer language ("raw" to the printer, no further filters).
> This should be a gutenprint setting. Still there is no real
> differentiation of the _target_ for both printers (which
> should be different because those are two _different_ devices).
If I replace the "lp" cmd with "/usr/local/bin/lp" (the cups lp),
it works for the hp.
But if I do the same for the epson, the cups admin page shows the
job in state "Connected to Printer" and it stays there forever.
The printer never wakes up, however.
There is a process:
22220 ?? S 0:00.06 socket://12.32.36.77:9100 298 garya (stdin) 1 finishings=3 number-up=1 job-uuid=urn:uuid:299661f4-82d6-3
But it never completes and the printer never wakes up.
Ah, ugh. After much fiddling, I discovered the printer was in a weird
state -- it wouldn't eject the paper in the rear manual sheet feed.
I had to turn it off (which fed the paper through) and on to reset the
state. At that point it would eject the sheet if I told it to. And
it also prints now.
Apparently the initial print attempt put it in a weird state, effectively
blocking anything from going to it even though it indicated it was in an
idle state. Or something like that.
>> arrgh!
>
> Yes, that's a typical sound when dealing with printers. :-)
>
> Again, make sure you're running _either_ lpd (OS service) _or_
> CUPS (3rd party toolset). Having both running _might_ be the
> cause of the problem.
Thanks
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53180D2B.9000509>