lpsched Issue

[MarkyC1978]

Hi all,

I found this forum after searching for similar issues (with no luck, obviously).  First, I should probably point out that I'm not an OS administrator, more an application administrator with OS access.  We currently have a strange issue with our lpsched process, running on HP-UX 11.31.  I'm hopeful and optimistic someone might have seen it before.  We have four servers with the same OS, and three behave perfectly fine, but there is always a bad egg.

When it comes to said bad egg, the process refuses to start when using command line /usr/sbin/lpsched.  I've also tried from actually within the directory, and this makes no difference as I probably should have expected.  The process does actually start for a few seconds (visible with ps -ef), but then stops for no apparent reason.  I haven't found anything of interest in the logs (or at least, not in the ones I've been looking at).  What is strange, is that it starts fine in SAM/SMH.  Essentially, our current workaround is to start the spooler using this method.  I cannot see what SMH is doing differently, it still starts the very same (I think) lpsched process, but it must be doing something above and beyond just running the lpsched command.  A look at the process, once started after using SMH, just looks normal;

lp 21354 21023 0 13:36:52 ? 0:00 lpsched

No frills, and no options shown.  We have had server restarts, which again result in the lpsched process not running, and requiring a restart from within SMH.  As I said, none of our other servers have this issue, so it's a bit strange.  I wondered if I could pick someone's brain in here, and hope that maybe someone has some ideas?

Kind Regards,

Mark

[Bill Hassell]

So start with the basics:

Is lpsched identical on the 4 servers?
The only way to be sure is to run cksum, what and ll on the executable:

# cksum /usr/sbin/lpsched
1389861021 231324 /usr/sbin/lpsched
# what /usr/sbin/lpsched
/usr/sbin/lpsched:
lpsched.c $Date: 2014/07/30 09:56:17 $Revision: r11.31/6 PATCH_11.31 (PHCO_43431)
lpio.c $Date: 2011/04/02 13:42:49 $Revision: r11.31/4 PATCH_11.31 (PHCO_41375)
outputq.c $Date: 2014/07/30 09:57:34 $Revision: r11.31/1 PATCH_11.31 (PHCO_43431)
genfuns.c $Date: 2014/09/11 03:56:15 $Revision: r11.31/7 PATCH_11.31 (PHCO_43431)
fifo.c $Date: 2009/10/21 17:10:32 $Revision: r11.31/1 PATCH_11.31 (PHCO_40128)
$Revision: @(#) lp R11.31_BL2014_0919_1 PATCH_11.31 PHCO_43431
# ll /usr/sbin/lpsched
-r-sr-xr-x 1 root bin 231324 Sep 18 2014 /usr/sbin/lpsched

Now the above results are just for this particular server and may not be the same as yours.

The other task is to see how SMH is starting lpsched. Look at the SMH logs to see how it is run.

Do you have core files in the directory you're in when running lpsched manually?
Does dmesg report anything?

Have you tried running lpsched with -v for more details in the lp log?

[MarkyC1978]

Firstly, thanks for the reply Bill, much appreciated.

I've ran cksum, what as you suggested (comparing with just one other server), and without wasting space posting the result, they're identical.  ll as well, all permissions are the same, file size and even the date.

I'd already looked at the SAM logs, which aren't really much help, as they don't explicitly give the commands that they're running.

Getting information about printers succeeded.
@!@8@1458221802@0
Exiting Task Manager with task lp_list_printers.
@!@2@1458221806@0
Starting print spooler...
@!@8@1458221806@0
Entering Task Manager with task lp_lpsched.
@!@2@1458221806@0
Starting the lp scheduler
@!@2@1458221806@0
Executing the following command:\Clpsched \C
@!@2@1458221806@0
Command completed with exit status 0.
@!@2@1458221806@0
Starting the lp scheduler succeeded.
@!@8@1458221806@0
Exiting Task Manager with task lp_lpsched.

I'm not sure if there are any settings to increase the trace level on that.

I did notice some core files in the /usr/sbin directory, but they are from years ago.  Just to rule them out though, I'd already moved them and retried with no luck.

dmesg doesn't report anything relating to lpsched, just a few unrelated messages about nfs.

I did actually try running lpsched -v but all that appears in the lp log is the date stamp before the process then dies;

***** LP LOG: Mar 17 13:23 *****

It's a bit strange really.

[Dennis Handly]

You could try tusc(1) on the good and bad systems and see where they diverge.

And look for errors on the last few lines of the bad one.

[MarkyC1978]

Unfortunately, we don't appear to have tusc installed :(

[Dennis Handly]

>we don't appear to have tusc installed :(

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-8.1/