Date: Thu, 6 Mar 2014 07:13:05 +0100 From: Polytropon <freebsd@edvax.de> To: freebsd@dreamchaser.org Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: printer woes Message-ID: <20140306071305.84f5ca15.freebsd@edvax.de> In-Reply-To: <53180D2B.9000509@dreamchaser.org> References: <5317C0E7.5010105@dreamchaser.org> <20140306023944.707250df.freebsd@edvax.de> <53180D2B.9000509@dreamchaser.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 05 Mar 2014 22:52:43 -0700, Gary Aitken wrote:
> 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...
That's _very_ complicated because it is so "modern". :-)
> Cups installs its own version of lp, lpr, lpstat, lpq...
Correct - except you use a port option to overwrite the
system's tools ("overwrite base").
Note that the system's LPD does not have lpstat, that is
CUPS-specific. Instead, it has lpc.
> 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.
Correct. And usually, the system's lp will not write to
the CUPS input queue, or probably fail because no printer
is configured (in a "LPD sense").
> >> 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.
But if you check http://localhost:631, the CUPS web interface,
all printers are present, enabled, active, and the printer jobs
don't show up?
> >> 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.
I'd assume that the printers aren't properly configured.
You can check that with the
$ lpc status all
command (which should list all printers defined in your system
and which status they currently have). You can also query each
individual printer with
$ lpq -P<name>
Note that there is no space between -P and the printer name.
For each printer, the message should be something like this:
$ lpq -PLaserjet-nodup
Laserjet-nodup is ready
no entries
If the printer is not ready, the input queues will fill up,
but no jobs will be released. In that case,
$ cupsenable <printer>
$ cupsaccept <printer>
will allow the printer to resume.
> >> 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.
Just as a dirty suggestion, you could rename the LPD tools in
the base to *.bsd so they won't be called "accidentally" as
they are still preceding in $PATH. The binaries affected are
/usr/bin/lp.bsd, /usr/bin/lpq.bsd, /usr/bin/lpr.bsd, and
/usr/bin/lprm.bsd.
> >> 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
Good, so no networking issue here.
> > 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.
This assumes that the printer can understand PS. If it does,
there is actually no need for printer filters (gs or gutenprint
or whatever), because PS is already the standard output format
for printing by any application.
If you know that, for example, the printer speaks PCL, you need
to preprocess the PS data. For example:
$ /usr/local/bin/gs -q -dBATCH -dNOPAUSE -dPARANOIDSAFER \
-dSAFER -sPAPERSIZE=a4 -r600x600 -sDEVICE=ljet4d \
-dDuplex=true -sOutputFile=/tmp/file.pcl file.ps
$ /usr/bin/printf "\033&k2G" | nc <printer-ip> 9100
$ nc <printer-ip> 9100 < /tmp/file.pcl
I'm using "ljet4d" here because this produces fine PCL.
> >> 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.
Check if the printer is fully available.
$ lpc status <printer>
Look for the entries "queuing is enabled" and "printing is enabled".
See prior example to unlock the printer if those are not set.
> 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.
That _could_ be if the connection to the printer has been
made, but the data does not "flow" because of some wait
state...
> 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.
Sometimes even rebooting a printer helps. :-)
> 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.
That is possible. Some printers (for example HP Laserjet 4000)
show a diagnostic message on the display for "mangled input" and
urge you to press the "Abort" button, so it can come into a normal
state again.
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140306071305.84f5ca15.freebsd>