APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Spoiled Brat Printers

I really enjoyed this "Your printer is a spoiled brat" cartoon. It's funny, but oh so true: printing is a source of a lot of problems and frustrations.

There are over 240 posts here about printing. When I think back over more than a quarter century of computer support, a lot of what I remember is printer problems. My wife's most common computer complaint from her XP machine? Her printer isn't working or is printing too small, too big..

From the Unix side of things, the only time I have printer problems here in my office is when the printer forgets its IP address. Other than that, no issues. At the same time that my wife's XP is saying the printer isn't ready, I can happily print.

You can test printers by bypassing all spooling and going direct to the printer itself. That's true even for network printers: I use this simple Perl script for HP and other "port" printers:


#!/usr/bin/perl
use IO::Socket;
$host=shift @ARGV;
$port=shift @ARGV;
$socket=IO::Socket::INET->new(PeerAddr=>$host, PeerPort=>$port, 
Proto=>'tcp', Type=> SOCK_STREAM) or die "Can't talk to $host 
at $port";

while (<>) {
print $socket $_;
}
close $socket; 
 

You'd use that like this:

perlnetcat.pl 192.168.1.14 9100 testfile
 

If that puts "testfile" on the printer, your spooler is confused.

My current printer problem

I've got a very strange printer problem at a customer's warehouse. Here's the setup: a few times per day they print out ten 4-5 page reports. These are coming across a vpn link from the main office. All ten reports just follow each other in a row, no pause. The first time they do it, the reports stop about half way through, printing about half the total pages.. not half of each report; half of the set of ten.

We all know that when something stops like that, it's flow control. In this case this is on an HP print server, so you'd say the buffer fills up and the flow control fails so the rest of the jobs get lost. Sure, but that doesn't explain why they can follow up with the same set of jobs and they WILL print. The printer will continue to be fine all day long unless.. unless it goes more than an hour without printing anything.

So just send something short before the first long job in the morning? Nope, that doesn't help.

That's just weird. Obviously it's something to do with the print server, but those symptoms are beyond strange.. right now, I'm baffled.

Your printer is a spoiled brat, indeed.



Got something to add? Send me email.



4 comments



Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence







Sun Mar 15 16:39:24 2009: 5712   BigDumbDinosaur

gravatar
You can also test any networked printer that accepts input via a port (e,.g., port 9100 on an H-P JetDirect) using netcat if available. For example:
echo 'This is a test' | netcat -dh <ip_addr> -p <port>


Also, some print servers will accept input via FTP.





Wed Mar 18 21:08:51 2009: 5750   MikeHostetler

gravatar
I don't know why I'm go to throw out ideas -- printers hate me. They go out of their way to make my life miserable. But here I got . . .

Does the print server log any sort of message when it stops?

Is print server used in some other capacity as well? Maybe it starts doing something else in the middle of the print jobs and forgets to complete them.

Check the print buffer . . . again, this goes to the above problem.

What happens if the main office sends the reports one at a time?

I'm curious what the final solution will be. Will you please share?






Wed Mar 18 21:14:29 2009: 5751   TonyLawrence

gravatar
Oh, of course - I always share :-)

No idea on logs in the print server - forgot to point that at a syslog server - doing that now!



Mon May 4 21:55:37 2009: 6320   AndrewSmallshaw

gravatar
Well I notice that this post is six weeks old now so hopefully you have come up with some kind of resolution by now. However, it reminds me of some issues I had with a self-designed serial to parallel converter a few years back. Initialising the printer takes time and during this time it would initially not assert flow control correctly - it was such a seemingly fringe issue I never considered it. More modern printers have higher speed links and larger buffers so any flow control issues will take much longer to materialise. However, if I am thinking along the right lines any fix would be in the print servers firmware. In other words outside your control so we can forget about that.

A more practical possibility is of course to fudge the issue. Send it a null job from e.g. cron every hour or whatever and hopefully it will get its initialisation out of the way before a real job comes along. The script below is a null job for PJL-compatible printers - that includes most recent PCL5 printers and many Postscript ones. It shouldn't cause anything to be printed and the printer will still be ready for the next job. It will just fool the print server into thinking it has sent something to the printer recently.

@PJL
<ESC>%-12345X

------------------------
Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





C is quirky, flawed, and an enormous success. (Dennis Ritchie)

In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg. (Bjarne Stroustrup)







This post tagged: