lpsched taking 90% CPU

[Ian Lochray]

A customer has got into a mess with their printer scheduler. How they got into the situation is unclear but the situation now is that, every time they start lpsched it takes 90% of the CPU. I have tied stopping lpsched with lpshut, removeing *FIFO* and SCHEDLOCK and restarting lpsched but the same thing happens. Even a reboot did not help.
Nothing is being written to /var/adm/lp/log.
Can anyone help please?

[A. Clay Stephenson]

You probably have a corrupt queue. Restart lpsched and then do an lpstat -t. Start canceling requests until either the problem disappears or all outstanding jobs have been cancelled. You actually may have many lpscheds running so do your lpshut thing and then see if any lpscheds are still running. If so, kill 'em. Lpsched forks so it is normal to have multiple lpscheds running briefly.

[Ian Lochray]

Thanks for the speedy response.
When I raised this issue there was only one lpsched process. This had been the case for abput 15 minutes since I had restarted the process. That process was taking 90% of tee CPU. Now, five minutes later, everyhimg is working perfectly. There is one lpsched process that is a child of the root process and several more that are children of that one. Files are printing and CPU usage is low.
What I need to know now is what was lpsched doing for 20 minutes taking 90% CPU and why did it stop doing it and start working again?
There are no clues in the log file.

[A. Clay Stephenson]

Did the /var file system fill up at any time? More than any other file system, /var can induce truly bizarre behavior.

[Ian Lochray]

No sign in the syslog of any file system filling up.

[Ian Lochray]

The problem was that the customer has lots of queues which were no longer being used. In fact, the printers or the PCs they were connected to had been switched off. When lpsched started up it took a while to check the status of each of these which resulted n quite a bit of time cumulatively.