comp.unix.sco Technical FAQ 7/9

Questions and Answers Related to Printing

Please read this disclaimer

MUCH OF THE MATERIAL AT THIS SITE IS RELATED TO SCO OSR5. OSR5 is Unix, so SOME of what you'll find here is useful if you are running Unixware, Solaris, Linux or whatever, but if your specific OS is not specifically mentioned, take whatever you read as being POSSIBLY WRONG FOR YOU.

FAQ Starting Page

The best way to find something is to use the Search Tools at this site. Every FAQ article is extensively indexed, so that really is the best way to find anything. Try it before you get eyestrain reading through the index. The searches also index other material NOT in the FAQ, which is yet another reason to use them.

Got something to add? Send me email.

(OLDER) <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> SCO Unix comp.unix.sco Technical FAQ 7/9


Increase ad revenue 50-250% with Ezoic

Sat Apr 22 22:39:15 2006: 1952   anonymous

I needed to migrate from serial printers to network printers using (D-Link and Netgear) print server devices. Unlike a Unix system, those devices have no understanding of printer capabilities. I therefore needed to retain the interface mechanisms used with local printers. I fell upon your suggestion of diverting printing to a remote printer using a named pipe and a perpetual script with enthusiasm, and at first it appeared to work brilliantly. However, disappointment set in when garbled print came out of busy printers. This is, I think, caused by a rapid succession of lp jobs for the same printer that write concurrently to the same named pipe. It seems that the lp system relies on the ability of a process to lock a tty for exclusive writing, and to wait if it finds a locked tty; I am not aware of a similar feature for named pipes. The remedy seems to be to amend the interface scripts to invoke the remote print instead, as I believe you and others have suggested elsewhere, and abandon the neat but, it seems, flawed approach of using a named pipe.

Sun Apr 23 11:11:08 2006: 1953   TonyLawrence


The lp system gives a job exclusive use of the pipe until the job is finished, so there is no overlap.

On a very busy system, it's possible for the lp system to send new data to the pipe before your reader process has sent it to the print server. You could implement a cooperative locking system to prevent that, but a small sleep at the end of the interface script will probably work.

Sun Apr 23 23:20:25 2006: 1955   BigDumbDInosaur

I doubt that either the lp subsystem or the named pipe are to blame. As Tony said, the lp subsystem processes one print job per printer at any given time -- there is no concurrent output. Therefore, as long as the data flow to the named pipe is coming only from lp, you should not be experiencing intermixing. The pipe itself is a sequential data conduit. Bytes will be read from the output end in the exact order in which they were written to the input end -- you can count on it!

There are several possiblities that come to mind, but not necessarily applicable to your situation, since I don't have the system in front of me. One is that TCP flow control is not being correctly implemented at the receiving end. Are you sure the printer server device attached to the printer correctly implements the ACK/BUSY sequence on the printer side? Also, when the printer asserts BUSY (which you can simulate by taking it off-line), does the printer server correctly do a TCP NACK, which should stall data flow (check that with netstat)? Is there more than one process writing to the named pipe, causing data to get intermixed and confusing the printer? lp won't do this but something else could without you knowing it. You didn't say exactly how you are reading out of the pipe and sending it onward to the printer. If using netcat, are you sure that only one instance of netcat is running and connected to the print server?

Oh, one more thing. Junk that Netgear stuff. Those things, in my opinion, make far better door stops than network printer interfaces. The best external print servers are the HP JetDirect 300 models. I have some around here I bought in the mid-1990's that are still working like a charm.

Sun Apr 23 23:31:50 2006: 1956   TonyLawrence

BDD makes good points, but I still see the possibility of a race condition here on the reader side. BDD's advice should certainly not be ignored but if the race does exist, it won't be fixed this way.

Do check the netgear with the printer off-line: I've definitely seen that problem with these cheap units.

Mon Apr 24 03:52:49 2006: 1957   BigDumbDinosaur

The race condition that Tony is speaking of will probably come at the end of the run, when all bytes have been read from the named pipe but, for whatever reason, the last buffer full has not been flushed to the target printer (a network propagation delay could account for this behavior, but on a LAN, a temporarily full buffer at the printer end -- or the printer being off-line -- is most likely the cause).

In any case, as soon as lpcat (the part of the lp subsystem that actually drives the printer) finishes with the first job, lpsched will spawn a new instance of lpcat to start the next job for that printer, stuffing a new byte stream into the named pipe. The elapsed time involved between the end of the first job and the start of the second could be very short -- a few milliseconds if the server isn't very busy. Meanwhile, assuming that all data from the previous job has not been flushed, there will still be a TCP connection opened to the print server for that job, yet the new job may have set up another connection. This sequence of events, which is permissble under the rules that govern TCP (in theory, any number of clients could set up a TCP link to a server, which is how a website like this one can handle many simultaneous hits), establishes the race condition. Now the question is, when the data stream stall clears, which connection -- that is to say, which print job -- will get to go first? If it's the old job you're okay. If the new one gets in there first (due to kernel scheduling, perhaps), you have out of order data, and garbage on the paper.

Again, since I don't know how you implemented this setup, I can only speak in generalities. What you need to do is to insert something at the end of your code that verifies that all data has been flushed from the first job before processing the next one. In other words, you need to absolutely guarantee that only one TCP path to the target print server can be created at a time. Hope that gives you a few ideas.

Thu May 11 02:26:26 2006: 2013   TheMonster

I have a quibble with the techniques shown here for printing to network printers. You show the commands with actual IP addresses as the target. Unfortunately, those addresses change from time to time. When that happens, it can be a real pain to track down every place that the old address is used. So I recommend always putting the printer IP address and name in /etc/hosts, and using the hostname of the printer instead of the IP in your scripts. The IP ought to be documented in hosts anyway, unless you're using DNS, in which case it ought to be there instead.

If you build an interface that uses `basename $0` as the network address, it will automatically take the name of the printer.

That way, when you realize that the IP scheme you're using on your local network includes public IPs of an Air Force base, and you want to change it before you install DSL, so that you can avoid being arrested for trying to hack into DoD assets (true story for one of our customers, inherited from a smaller company we bought out several years ago.), you just edit the hosts file, and you're done.

Thu May 11 10:00:41 2006: 2014   TonyLawrence

True. I tend to show IP addresses here to make it plain that they ARE IP addresses.

Kerio Samepage

Have you tried Searching this 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

privacy policy