Printer Error Notifications Support

KB Home   |   Printer Error Notifications Support

Main.CupsErrorNotificationLimitations History

Hide minor edits - Show changes to output

February 28, 2019, at 07:03 AM by Tim Shimmin - mention snmp v3
Added lines 16-17:

Note that SNMP v3 support from PaperCut version 19.0, does not add SNMP v3 support for the Print Provider  and hence there is no SNMP v3 error notifications support in 19.0 (this will be done in a later release).
December 05, 2017, at 02:29 AM by peterf - Reworded/revised, and updated to reflect SNMP error monitoring for Windows in 17.4.2
Changed lines 3-4 from:
PaperCut tracks the error status of a printer. This printer error state is used by PaperCut for various features such as:
to:
PaperCut MF and PaperCut NG track the error status of your printers. This printer error state is used by the application for various features, such as:
Changed lines 6-24 from:
* Decide which destination printer to use for a virtual printer in a load-balancing setup.
* Informing users if they try and release a job to a printer in error during secure print release.
* Real-time status reporting on the PaperCut dashboard.

Under Windows, there is good support for printer errors due to the appropriate Microsoft [=APIs=] as described
here:
http://support.microsoft.com/kb/160129 and the driver support which pro-actively monitors the printer.

For Linux, Mac and Novell/Iprint, we use a program called pc-event-monitor which creates processes for monitoring the printer state using the data retrieved from the printers using SNMP (this was added in PaperCut 12.3).

Q: What do the pc-event-monitor processes do?

A: The pc-event-monitor creates a number of different processes on Linux, Mac and Novell. The purpose of these processes includes:

#
for CUPS (Linux/Mac), we look for new printer jobs and make "prenotification" calls that a new job has started to the pc-client before print job analysis has been done (i.e. before the file has finished spooling)
# for CUPS (Linux/Mac), we monitor the /etc/cups/printers.conf file for changes when printers are added/removed
# for Iprint (Novell), we monitor
the iprint/padbtxt.xml file for changes when printers are added/removed
# determining if a held job has been released yet
# monitoring of the SNMP error data for
the printers
# if any printer goes into error state then a separate process to monitor the printer is created and will be around until the printer is out
of error state again
to:
* Deciding which destination printer to use for a virtual printer in a load balancing setup.
* Informing users if they try and release a job to a printer in error during Secure Print Release.
* Real-time status reporting on the Dashboard of the Admin web interface.

Under Windows, there is good support for printer errors due to the appropriate Microsoft [=APIs=], as described
here:
http://support.microsoft.com/kb/160129, as well as driver support for the proactive monitoring of printers.

For Linux, macOS, and iPrint, we use a program called [@pc-event-monitor@] which creates processes for monitoring the printer state using the data retrieved from said printers using SNMP. This was added in PaperCut MF and PaperCut NG versions 12.3.

As of version 17.4.2 of PaperCut MF and PaperCut NG, the Print Provider on Windows print servers can be reconfigured to also use SNMP to check for printer error states, instead of  solely relying on updates from the Windows print queue. In some circumstances, this may result in error states being reported more quickly and responsively. For example, you may notice a delay between an error first occurring at a printer and it's subsequent reporting via the Windows print queue when using the PaperCut TCP/IP Port, instead of the Windows Standard TCP/IP Port with SNMP enabled (this is a requirement for our [[https://www.papercut.com/products/ng/manual/applicationserver/topics/printer-hwcheck.html|Hardware Checks]] feature). To try it out, the [@ErrorPollMethod=snmp@] option can be enabled, as found in the [@[app-path]\providers\print\win\print-provider.conf@] configuration file on your Windows print server.

Q: What do these [@pc-event-monitor@] processes do?

A: The [@pc-event-monitor@] creates a number
of different processes on Linux, macOS, and iPrint. The purpose of these processes includes:

# For CUPS (Linux/macOS), they look for new print jobs and make "pre-notification" calls in order to advise the [@pc-client@] that a new job has been detected before print job analysis has been completed (i.e. before the print job has finished spooling)
# For CUPS (Linux/macOS), they monitor the [@/etc/cups/printers.conf@] file for changes when printers are added or removed
# For iPrint, they monitor the [@iprint/padbtxt.xml@] file for changes when printers are added/removed
# Determining if a held job has been released yet
# Monitoring of the SNMP error data for printers
# If any printer goes into an error state, then a separate process to monitor the printer is created, and will continue to run until the printer exits said error state
February 18, 2013, at 05:02 AM by Alec - Fixed English
Changed lines 24-25 from:
# if any printer goes into error state then a separate process to monitor the error'ed printer is created and will be around until the printer is out of error state again
to:
# if any printer goes into error state then a separate process to monitor the printer is created and will be around until the printer is out of error state again
Changed lines 15-16 from:
Q: What do all the pc-event-monitor processes do?
to:
Q: What do the pc-event-monitor processes do?
Changed lines 13-14 from:
For Linux, Mac and Novell, we use a program called pc-event-monitor which creates processes for monitoring the printer state using the data retrieved from the printers using SNMP (this was added in PaperCut 12.3).
to:
For Linux, Mac and Novell/Iprint, we use a program called pc-event-monitor which creates processes for monitoring the printer state using the data retrieved from the printers using SNMP (this was added in PaperCut 12.3).
February 18, 2013, at 01:22 AM by tim - update as we now have SNMP printer error support on Unix
Changed lines 1-2 from:
(:title Printer Error Notification Limitations on Linux and Mac :)
to:
(:title Printer Error Notifications Support :)
Changed lines 12-23 from:
Unfortunately, there is not the same level of printer error support in the CUPS API.
Currently in CUPS,
the error status is not determined until '''after''' sending the print job.  This post-event type notification is OK for selected error status related features such as emailing an administrator, but it's too late to be used for features like selecting a printer automatically in a load balancing pool.

We currently have plans to create
a Unix process for periodically monitoring the state of the printer
via SNMP requests. This will be completely independent of CUPS and a core PaperCut component.  R&D in this area is complete, development is done and will be released in PaperCut 12
.3.

Q: Does SNMP Hardware Validation Checks help in this situation?

A: No, it currently does not help. If the Hardware Validation checks are turned on, then
the
PaperCut ''backend'' will block waiting for the printer to get out of the error state, before it
even attempts to send on the print job to
the printer (via the original CUPS ''backend'').
to:

For Linux
, Mac and Novell, we use a program called pc-event-monitor which creates processes for monitoring the printer state using the data retrieved from the printers using SNMP (this was added in PaperCut 12.3).

Q: What do all the pc-event-monitor processes do?

A: The pc-event-monitor creates a number of different processes on Linux, Mac and Novell. The purpose of these processes includes:

# for CUPS (Linux/Mac), we look for new printer jobs and make "prenotification" calls that
a new job has started to the pc-client before print job analysis has been done (i.e. before the file has finished spooling)
# for CUPS (Linux/Mac), we monitor the /etc/cups/printers.conf file for changes when printers are added/removed
# for Iprint (Novell), we monitor the iprint/padbtxt
.xml file for changes when printers are added/removed
# determining if a held job has been released yet
# monitoring of the SNMP error data for
the printers
# if any printer goes into error state then a separate process to monitor the error'ed printer is created and will be around until
the printer is out of error state again
Changed line 27 from:
[-Keywords:  virtual printer errors, snmp, cups, out of paper -]
to:
[-Keywords:  virtual printer errors, snmp, cups, out of paper -]
Changed lines 16-17 from:
via SNMP requests. This will be completely independent of CUPS and a core PaperCut component.  R&D in this area is complete and development is underway.
to:
via SNMP requests. This will be completely independent of CUPS and a core PaperCut component.  R&D in this area is complete, development is done and will be released in PaperCut 12.3.
Changed lines 16-17 from:
via SNMP requests. This will be completely independent of CUPS and a core PaperCut component.  R&D in this area is complete and development will start soon.
to:
via SNMP requests. This will be completely independent of CUPS and a core PaperCut component.  R&D in this area is complete and development is underway.
Changed lines 13-14 from:
Currently in CUPS, the error status is not determined until '''after''' sending the print job.  This post-event type notification is OK for selected error status related features such as emailing and administrator, but it's too late to be used for features like selecting a printer automatically in a load balancing pool.
to:
Currently in CUPS, the error status is not determined until '''after''' sending the print job.  This post-event type notification is OK for selected error status related features such as emailing an administrator, but it's too late to be used for features like selecting a printer automatically in a load balancing pool.
Changed lines 19-20 from:
No, it currently does not help. If the Hardware Validation checks are turned on, then the
to:

A:
No, it currently does not help. If the Hardware Validation checks are turned on, then the
Changed line 25 from:
[-Keywords:  virtual printer errors snmp -]
to:
[-Keywords:  virtual printer errors, snmp, cups, out of paper -]
Changed lines 3-7 from:
In PaperCut, we have an associated printer error state with a printer.
This printer error state can be used in the decision making by the PaperCut Application Server,
for example to decide which destination printer to use for a virtual printer.
In this case, the Application Server would choose a destination printer that is not
in error.
to:
PaperCut tracks the error status of a printer. This printer error state is used by PaperCut for various features such as:

* Error notification emails to administrators.
* Decide which destination printer to use for a virtual printer in a load-balancing setup.
* Informing users if they try and release a job to a printer
in error during secure print release.
* Real-time status reporting on the PaperCut dashboard
.
Changed lines 13-17 from:
Currently in CUPS, the error status is not determined until after sending the print job, where we look at the
CUPS ''backend'' exit status to decide whether to notify the Application Server of a printer error.
However, this is often not adequate enough as the printer ''backend'' may not give an error exit status
(as we are expecting) or may block if the printer is in error
.
to:
Currently in CUPS, the error status is not determined until '''after''' sending the print job.  This post-event type notification is OK for selected error status related features such as emailing and administrator, but it's too late to be used for features like selecting a printer automatically in a load balancing pool.
Changed lines 16-18 from:
via SNMP requests and reporting the error state back to the Application Server. This will be completely
independent of CUPS
.
to:
via SNMP requests. This will be completely independent of CUPS and a core PaperCut component.  R&D in this area is complete and development will start soon.
Changed lines 9-13 from:
http://support.microsoft.com/kb/160129.
Unfortunately, there is not the level of printer error support in CUPS
. Currently, we look at the
CUPS backend exit status to decide whether to notify the Application Server of a printer error.
However, this
is often not adequate enough.
to:
http://support.microsoft.com/kb/160129 and the driver support which pro-actively monitors the printer.
Unfortunately, there is not the same level of printer error support in the CUPS API.
Currently in CUPS, the
error status is not determined until after sending the print job, where we look at the
CUPS ''backend'' exit status to decide whether to notify the Application Server of a printer error.
However, this is often not adequate enough as the printer ''backend'' may not give an error exit status
(as we are expecting) or may block if the printer is in error
.
Changed lines 21-22 from:

to:
No, it currently does not help. If the Hardware Validation checks are turned on, then the
PaperCut ''backend'' will block waiting for the printer to get out of the error state, before it
even attempts to send on the print job to the printer (via the original CUPS ''backend'').

Changed line 3 from:
In PaperCut, we have an associated printer state with a printer.
to:
In PaperCut, we have an associated printer error state with a printer.
Changed line 8 from:
Under Windows, there is good support for printer errors due to the appropriate Microsoft APIs as described here:
to:
Under Windows, there is good support for printer errors due to the appropriate Microsoft [=APIs=] as described here:
Changed lines 1-2 from:
(:title Printer Error Notification Limitiations on Linux and Mac :)
to:
(:title Printer Error Notification Limitations on Linux and Mac :)
Changed lines 1-2 from:
(:title Printer Error Notification Limitiations on Linux and Mac Title:)
to:
(:title Printer Error Notification Limitiations on Linux and Mac :)
Changed lines 20-23 from:
!!Subheading

TODO link your page here: https://www.papercut.com/kb/Main/Miscellaneous

to:
Deleted lines 21-22:
''Categories:'' [[Category.TODOFirstCategory|+]], [[Category.TODOSecondCategoryIfNeeded|+]]
----
Added lines 1-27:
(:title Printer Error Notification Limitiations on Linux and Mac Title:)

In PaperCut, we have an associated printer state with a printer.
This printer error state can be used in the decision making by the PaperCut Application Server,
for example to decide which destination printer to use for a virtual printer.
In this case, the Application Server would choose a destination printer that is not in error.

Under Windows, there is good support for printer errors due to the appropriate Microsoft APIs as described here:
http://support.microsoft.com/kb/160129.
Unfortunately, there is not the level of printer error support in CUPS. Currently, we look at the
CUPS backend exit status to decide whether to notify the Application Server of a printer error.
However, this is often not adequate enough.

We currently have plans to create a Unix process for periodically monitoring the state of the printer
via SNMP requests and reporting the error state back to the Application Server. This will be completely
independent of CUPS.

Q: Does SNMP Hardware Validation Checks help in this situation?

!!Subheading

TODO link your page here: https://www.papercut.com/kb/Main/Miscellaneous

----
''Categories:'' [[Category.TODOFirstCategory|+]], [[Category.TODOSecondCategoryIfNeeded|+]]
----
[-Keywords:  virtual printer errors snmp -]

Comments

Share your findings and experience with other PaperCut users. Feel free to add comments and suggestions about this Knowledge Base article. Please don't use this for support requests.

Article last modified on February 28, 2019, at 07:03 AM
Printable View   |   Article History   |   Edit Article