Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We have a Windows Server 2003 R2 machine running an LPD service for us as part of an ERP implementation. I use Nagios to monitor the network and have this host set up already. I am now trying to set up a service to monitor the Windows LPD service which runs on this host and ensure nothing sits in the queue too long. I found http://exchange.nagios.org/directory/Plugins/Operating-Systems/Linux/check_lpstat/details but I feel like I am losing my mind trying to configure it!

Nagios runs on ubuntu 10.04. I needed a package with lpstat, so I tried cups-client. lpstat -h [servername] just returned lpstat: transport endoint is not connected, and google gave me nothing on the error message except sparse bug reports for unrelated situations (install related mainly) so I tried lprng, which wanted me to first generate /etc/printcap, but I am not interested in the Nagios box offering print services so I abandoned that too. I started looking for another option and installed the lpr package hoping to make use of the lpq command I had seen in some of my google searches. Unfortunately, what I had seen must have been for a different implementation because it wouldn't accept the -H option (or anything else I could see to specify a remote host).

Obviously I am not going down the right track here. I know I can just telnet [servername] 515 and make sure I make a connection, but that is just going to tell me the port is open, right? That could return success and still there be an error holding a queue, right? (seriously, because if I am assuming wrong on those last two counts then I am making this needlessly hard).

share|improve this question

1 Answer 1

up vote 2 down vote accepted

You are correct, a simple TCP connection isn't going to reliably tell you the system is operational.

lpstat will try to connect to the IPP port, I believe the LPD service on Windows provides just a standard unix lpr on port 515 (see http://technet.microsoft.com/en-us/library/cc728404.aspx ).

The NagiosExchange check_lpq isn't a good solution here. You might be able to get away with using check_grep as a wrapper around lpq, you'll either need an lpq that will connect directly to the printer, or one that can connect via a working CUPS or lpr-ng.

This is probably your best bet: http://planet.pks.mpg.de/trac/site/browser/src/nagios/plugins/check_lpr.pl?rev=178&order=name

(click the "Original format" link below the source to download just the source). You'll need a working perl and the Net::LPR module. You may need to hack it a bit, especially if you need to add logic to detect stuck jobs. I can't say I've used it heavily, but it has worked fine for me with real printers and lpd (lpr-ng), though I have not used it with Windows/LPD.

$ perl check_lpr.pl -v -H hp1f01 -P Auto
OK - JetDirect lpd: no jobs queued on the port Auto

You could also consider using check_nrpe and nrpe_nt (or similar) with service/process checks on the Windows system to make sure the services are running correctly; or some powershell to query the print queues directly (e.g. via WMI).

share|improve this answer
    
Thanks very much for the help, I think the PS/WMI route is likely where I'll go, seeing as NSC++ is already installed on the host for general "is it turned on" monitoring. –  Chris O'Kelly Mar 26 '13 at 5:11

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.