Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

In our production environnment, I have a printer which users print to from a Unix (AIX) application called iMX (based on Java and Oracle Forms, if that matters) The official documentation page is there http://www.codix.eu/download.php?language=eng if you need any very general info.

The problem is that at some point during the day, generally when the load gets higher, the printer stops printing documents that iMX sends, because one document gets kind of "stuck".

Every of our end-user have :

  • A login/password they use to open a session on their Windows XP workstation
  • A different login/password they specifically use to connect to iMX once they opened their iMX client

The server side of iMX runs on the AIX server with a generic account 'imxUser', the same which processes print requests from iMX users (see lpstat below).

The faulty printer is also directly reachable from Windows (XP, mostly) clients, ie people can "see" it in their printer manager. They can print Word documents or other things from their workstation, that always work. Please note that this faulty printer is of a different brand than most we use. The supplier has come to check the printer once but nothing came of it.

Lpstat (I removed the Files and User information):

Queue   Dev   Status    Job Files              User         PP %   Blks  Cp Rnk
------- ----- --------- --- ------------------ ---------- ---- -- ----- --- ---
pName     @pName  CONNECT   545 xx.user.xx     imxUser               25   1   1

: (WARNING) Connection to server timed out after retrying.
rembak: errno = 79: Connection refused
pName     pName   HOST_DOWN
  • ping pName works okay.
  • If 'imxUser' prints something from a terminal with 'lp -d pName filename', it gets queued, and sits forever in the queue, at least until job 545 is manually cancelled (either through 'cancel' in terminal, or by clicking on "reinit printer" on the printer remote web access).

I can't reproduce this problem at will, it is reproducable once or twice per day (when load is high enough). When that happens, the end-users simply configure their workstation to use a different printer as default for iMX, so this problem is not blocking. However, we will eventually have to resort to switch to a printer of a different brand even though we can't even be sure that would solve the problem.

The jobs that get stuck have nothing common between them.

I'm at a loss here, due to my limited knowledge in printers/Unix (I can check things but I can't take the risk of breaking anything on a production server), the very bad reproducibility which relies on end-users' action, and the network environnment and configuration which I'm not too familiar with (not of my doing and I don't have actual control over it).

What would be the right approach here, and the right things to look for ?

VERY important EDIT (sorry I forgot to say that before the first answer) :

  • I can unstuck the things if I manually cancel the current job after people told me they can't print anymore, but that has to be done manually and stays unexplained.
  • I don't have root access on the server (I only have access to the imxUser, and my own personal user, which can probably do about nothing), if I have to do things as root, I will have to forward them to other people.

PS. Please ask if you need any more information

share|improve this question
add comment

1 Answer 1

I've seen similar problems with print queues using the LPR/LPD protocol on other (non-AIX) Unix systems. The causes seems to be that the host system (your AIX system) has problems communicating with the printer and eventually gives up on it and marks that printer as "down"

Restarting the queue

Sometimes you can restart the queue by cancelling the stalled print job. presumably this stimulates the server to check if the printer is still "down".

Sometimes you can get the print queue processed by stopping and restarting the print queue subsystem. If AIX has lpshut and lpsched try running those commands as root.

Use a different protocol

Sometimes you can prevent the problem occurring by switching to an alternate print protocol.

direct port printing

Most networked printers also support direct port printing (e.g. by sending data to TCP port 9100 for HP printers or HP Jetdirect print-servers). There may be a recipe for setting this up on AIX. Solutions typically use netcat. Different manufacturers use different ports.

proprietary protocols

HP also have a proprietary protocol called HPNP - it may be worth seeing if AIX has support for this if your printers are HP or are connected via HP Jetdirect boxes.

FTP based printing Some print servers used to support printing using the FTP protocol. I'd be reluctant to try this but it may be an option. Often you can configure Unix print systems to use custom scripts for printing and this way you can set up even something like FTP to work as part of the system's normal printing process.

Fix the cause

The arguably best solution would be to fix the network unreliability that causes AIX to mark the printer "down" - but this can take some effort to track down and diagnose.

Suggestion

I'd try direct port printing.

share|improve this answer
    
Thank you for this first answer, sorry but I have just edited my initial post to add that I already knew about cancelling (it is actually what I used to do when the problem arose). As for using a different protocol, that sounds interesting (provided I can use different protocols for separate printers that are configured on the same server). I will need more information about it and am going to look into it more using the information you gave. –  Toto May 28 '13 at 12:15
    
How can I check which protocol I am currently set to using ? –  Toto May 29 '13 at 8:59
    
Another question: are there also relevant logs to check ? (Unix side and printer side). I am lacking information that would allow me for precise troubleshooting. I actually need it, because I have other printers blocking from time to time but with slightly different signs –  Toto Jun 6 '13 at 14:06
    
@Toto: Check your syslog configuration (typically /etc/syslog.conf) - that will show where logfiles are written for each class of log data. –  RedGrittyBrick Jun 7 '13 at 8:50
    
@Toto: P.S. I think your printing problem is a system-level problem that should really be solved by the systems administrator (whoever has root access). If you can configure the application to use a custom print command instead of lp ... then you might be able to use a different protocol without root access - but I suggest you first consult the system administrator and then, if necessary, get management support for escalation of problem resolution. –  RedGrittyBrick Jun 7 '13 at 9:18
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.