Troubleshooting guide for 'RPM is not working'

Screenshots in this article are from RPM 7.0.

We have built a lot of RPM Remote Print Manager® (“RPM”) features for troubleshooting and diagnostics. In this article, we talk about some of that capability and how to use it.

“RPM is not working”

We see this vague but troubling statement from time to time. Let’s try to get to the bottom of this dilemma without pushing too many psychological buttons.

Is RPM running?

To verify whether RPM is running, launch the user interface. Let’s take a look at the lower right corner:

Notice the red plug with a line through it? That means the service is not running. When the service is running, the plug is green.

If RPM is not running, it will not receive jobs. You should start the service.

What if RPM won’t keep running?

1. With the latest RPM versions, rarely, the service will not start or stay running. If the UI also doesn’t run, that fact is helpful as it may provide clues into why the service is having problems. Please let our support staff know this when you contact us.
2. If the service does not stay running but the UI starts, it could be because of a job processing issue. Find the problem queue by suspending the queues and resuming them one at a time.
3. Also if the UI starts, you might review the event and message log for any errors and resolve issues found there.
4. Another good idea is to remove all unneeded configurations. For instance, remove unused queues, actions, and transforms, and remove all jobs that you don’t need or that you can reprint from the source.
5. Another potential cause for why the service will not stay running is a corrupt database. Check our database maintenance article for more information on fixing database issues.
6. Finally, if nothing listed above seems to help, then before you contact us, please go to the diagnostic log and make sure the following are selected: RpmSrv, app-start, app-stop, and ntservice. Then attempt one more restart of the RPM service. The log this effort generates will be useful. Thank you!

Find the problem queue

When the service stops, hangs or slows down while it is processing jobs, the cause is often the jobs in one queue. This is the quickest way we know to find which one:

1. In the Queue List, select each queue that has jobs and tick Suspend under Queue States. A suspended queue still receives jobs but does not process them, so nothing is lost.

   

2. Restart the RPM service. With every queue suspended, it should start and stay running.

3. Clear Suspend on one queue and watch its jobs run.

4. If the service stays up and the jobs finish, move on to the next queue. When the problem comes back, you have found the queue.

Then look at that queue’s jobs with Job Status, and check the message log for the time the problem came back. Often it is one job, or one action that can’t reach its printer or folder.

Is RPM stopped because the license is in trial mode?

No, RPM runs fine when the license is in trial mode. It may restrict some functions or add watermarks to some output, but in general, that is not a reason for RPM to not receive jobs.

If the RPM license is expired, it will not listen for jobs. In the user interface go to Help/License and check the status. If you have questions, contact our support staff.

Is RPM receiving jobs?

Let’s say you are printing to RPM and so far nothing has happened. If you ran the user interface and saw this:

I can tell you two things with certainty from this image:

1. RPM is running (the green plug-in icon at the lower right)
2. RPM has not received any jobs (the lack of queues in the queue list at the far left

Of course, this assumes you just installed RPM. We’re not talking about a working installation, because of course, you would have queues. In that case, take note of the “Total” column in the queue list to the far left. This is the number of jobs the queue has received. If this total never goes up, then you are not receiving jobs.

If it makes it easier, you can select one or more queues, then right-click and click “Reset total” to reset that number to zero.

Whether you have a new or established install, it’s worth noting that RPM is a listening agent. There is nothing you need to do or can do to “make” it listen. It will work whether you are in the trial period or have activated the license.

There are only three things that make a difference here:

1. Are you sending to the right address? You need to use the machine RPM is running on.
2. Is there a firewall issue?
3. Is there another software service listening on the port RPM needs to use?

Let’s address each of these questions.

How do I get the right IP address for the machine running RPM?

I typed this search into Google just now: “how to get IP address for windows”

Google suggested searches on Windows 10, Windows 7, Windows 8.1, and even Windows XP. Your best advice is to get specific information for your own Windows edition.

However, as far back as I can remember, Windows has used the “ipconfig” program which is similar to “ifconfig” in the Linux world. We take it for granted that all machines have “ipconfig” installed. If yours doesn’t, you might find out how to (again, use a search engine or ask someone you trust).

The ipconfig program has a lot of switches and options, but I don’t use any of those options to find my IP address. All I do is type the name of the program in the command window.

Near the top of the program’s output I have the following:

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : brooksnet.com
   IPv4 Address. . . . . . . . . . . : 192.168.89.132
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.89.1

Look for the line that says “IPv4 Address”. Note the value, which in my case is 192.168.89.132.

How do I troubleshoot firewall issues?

When you install RPM, the installer makes a firewall exception to allow it to receive data over the network. Beyond this, you’ll need to consult your network administrator or if you know which firewall you’re using, try searching for help for that product.

Here are a couple of firewall-related pages on our site that may be helpful:

• Add Windows Firewall Exception
• How do I configure my firewall?

We can’t keep up with firewall technology, mainly when it’s usually a “fix it once” problem. If your site changes its firewall policies or configurations, then keep in mind that RPM is a service that could be affected by such changes. That behavior is not typical for a Windows application.

How do I tell if another product is using the RPM port?

For reasons unknown to us, sometimes Microsoft will enable LPDSVC during a Windows update. It’s also entirely possible that you could install another program that provides LPD functionality which could also listen on the same port.

RPM will tell you in multiple places if it can’t launch the LPD listening port.

Here’s an example of the event log message:

Port in use - 2018-12-04 11:50:07.938
port: 515, process: C:\Windows\System32\svchost.exe

The message log entry uses code 413 (which is the unique message code, the 2nd column in the log viewer window. Here is a sample text:

Server port ‘515’ already in use by process [‘12072’] path ‘C:\Windows\System32\svchost.exe’

You’ll need to track down whatever that program is and find out how to disable it. Then, relaunch the RPM service.

If RPM is receiving jobs, what happens to them?

There are four ways to send jobs to RPM (LPD, telnet, app-sopcket, and folder watcher) and 3 of those 4 specify a queue name.

Note that they specify a name; if a queue by that name doesn’t already exist, RPM will create it by default.

Let’s say this happens to you. A few months ago. I set up a queue called “text” and added some setups that made sense at the time.

Then, I sent a few hundred jobs; nothing happened. I noticed that the user interface showed me, in the top left:

Somehow my jobs ended up in a queue called “test” instead of “text”. Note that “test” has an empty printer icon, meaning it has no setup. I had mistyped the queue name:

pylpr -p test@localhost d:\testing\data\latin1\b*

The easy way to move the jobs from the “wrong” queue to the one I intended is to add a copy queue action to test, run it, and then delete the queue unless I plan to make that mistake frequently.

Is your queue suspended?

One problem people run into is that someone has suspended the queue they are sending jobs to.

If you look in the UI, a queue that is ready to process has a green printer icon. A yellow icon indicates the queue is suspended.

Just above when I added the Copy Queue action, RPM showed me a dialog. We realized that many people configure a new queue but forget to resume it, that is, turn off the suspended setting. We recently added a test when you finish configuring a suspended queue. You might want to turn on processing for it:

If you see this dialog, that’s what is going on.

Remember, that a suspended queue won’t print.

Why isn’t a job processing? Check Job Status

Job Status is the most useful tool in RPM for this question. It tells you what RPM is waiting for, instead of leaving you to guess. Select the job in the Jobs list, then choose Job > Status, or right-click the job and choose Status. The window has two parts:

• Ticket Status shows one line for each ticket. RPM makes one ticket for each enabled action in the queue, and the line gives its number, its status and the action, such as Text Printer or Archive to Folder. When a job printed to one place but not another, this tells you which action failed.
• Ineligibility Reasons lists everything that is stopping RPM from processing the job right now. If it is empty, nothing is in the way, and RPM will process the job when it reaches it in the schedule.

What each reason means, and where to look:

The job’s Status column helps too. active means the job is processing now. rcvd means it has been received in full and is waiting to be scheduled.

What about jobs that are holding?

Let’s say you look at your job list in the user interface, and nothing is happening. The jobs have a “lock” icon, like this:

Note the “Hold” column is marked “Yes” for all these jobs.

If you want to release jobs individually, you can do this one at a time if you prefer or do as many as you like at once.

Here I have selected the first job:

To release it, click the Hold/Release Job toolbar button, the one with the lock icon, second from the right. You can also choose Job > Hold or press Alt+H. Each toggles the hold setting on every job you have selected.

Have you checked the Windows print queue?

I was recently stress-testing RPM, trying to reproduce a customer problem. I was using the text print action but rather than burn through several reams of paper, I set the printer port up to send to RPM on port 9100.

Occasionally I stopped getting print jobs in RPM. On my Windows 10 development machine, I went to the command bar and typed

Printers

I select the option “Printers & Scanners”.

The particular printer I was working with was

HP LaserJet 4200 PS Class Driver Telnet

Selecting that I got this menu:

From here I could choose Open Queue and manage my outstanding print jobs. Typically I would reprint on one or more jobs.

It’s worth knowing where Windows print jobs end up and no doubt there are many good tutorials on system administration in this area available on the Web. As far as I know, this Windows printer queue is the last spot you can affect your print jobs before they come out on the printer.

If you are concerned about the way RPM generates print jobs, go to the View / Devices in the user interface, then in the Devices tab double click on your device. Set the “Max Use” value to 1, which will queue jobs for that printer rather than allow multiple jobs in RPM to access the printer at a time. This may help.

What about Raw Printer actions where the jobs disappear from the Windows queue but fail to print?

I’m aware of two factors you need to take into account when you want to send print jobs using the Raw Print action.

Printers that use a Windows class driver are not one of them. Raw print to a class driver works in RPM 6.2.0.499 and later, including RPM 7: RPM checks the printer’s driver type and sends the job the way that driver needs. If you have an older RPM, upgrade. If you are still not sure whether the driver is the problem, create a new Windows printer on the same port using the “Generic / Text Only” driver and test with that.

The first reason we’re aware of that your raw print jobs won’t produce output is if the printer is not compatible with that data format.

In the past, I’ve been able to answer many questions about printers and data formats by merely doing a Web search on the word “specifications” followed by the printer manufacturer and model. I usually can find a specification page online which gives me the information I need.

RPM has built-in tools for converting specific data formats, and there is a lot of information available on tools for converting many types of data we don’t handle on our own. That’s why RPM has the filter action

The second reason is that a null character was not removed from the end of the print job before sending it to the printer. This caused some printers to reject the job. This problem only occurred with certain print clients. If you have an earlier version of RPM than version 6.2, you should upgrade when you have the opportunity. It may also be possible to use the string translate transform, depending on your data.