09-16-2011 03:38 PM
Bizarre problem with lpsched. I installed Wireshark to do some network analysis on my C3600 running 11.11 and now no users can print other than root.
Troubleshooting was done to determine the sticky bit is set everywhere it needs to be. The lock file is created and deleted normally when I start and stop lpsched and there are no problems doing that.
Information that could be helpful: If I'm logged in to CDE as root and "su user" to any user I can print using "lp" command with no problems. If I "su - user" I get the message "lp: Error - scheduler not responding". If I log into CDE as any user other than root, I get the same error when trying to print. If I then "su" I can "lp" files fine. If I "su - root" however I get the same error message and can't print. None of the user environments where changed during the Wireshark install but many dependencies where installed one of which was "cups". The others can be found here:
Any help would be appreciated!
Solved! Go to Solution.
09-16-2011 04:16 PM
>Troubleshooting was done to determine the sticky bit is set everywhere it needs to be.
That would be my first guess. Have you checked the directory permissions too?
>and "su user" to any user I can print using "lp" command with no problems.
That would imply it is some environment variable gone horribly wrong?
>If I log into CDE as any user other than root, I get the same error when trying to print.
Use tusc to track down the system call that is failing.
09-19-2011 08:48 AM
I decided to check permission again and I discovered an "lp" (and other lp files) on /usr/local/bin which don't exist on other machines I have. It did'nt have the UID bit set. I explictly printed using the /usr/bin/lp and I was able to print as other users. I added the UID bit to the /usr/local/bin/lp and lpstat, restarted lpsched and tried again but still got the same error.
/usr/local/bin/lp: Error - scheduler not responding.
Here are some directory listings:
-r-sr-xr-x 1 root bin 53248 Jun 2 2006 lpadmin
-r-xr-xr-x 1 bin bin 20480 Jun 2 2006 lpana
-r-sr-xr-x 1 lp bin 24576 Jun 2 2006 lpfence
-r-sr-xr-x 1 lp bin 28672 Jun 2 2006 lpmove
-r-sr-xr-x 1 root bin 53248 Jun 2 2006 lpsched
-r-sr-xr-x 1 lp bin 16384 Jun 2 2006 lpshut
-r-sr-xr-x 1 root bin 40960 Jun 2 2006 lp
-r-sr-xr-x 1 root bin 40960 Jun 2 2006 lpalt
-r-xr-xr-x 1 bin bin 614 Nov 14 2000 lpr
-r-sr-xr-x 1 lp bin 53248 Jun 2 2006 lpstat
-r-sr-xr-x 1 root sys 28672 Jul 28 08:52 lp
-r-xr-xr-x 1 root sys 28672 Jul 28 08:52 lpoptions
-r-xr-xr-x 1 root sys 28672 Jul 28 08:52 lppasswd
-r-xr-xr-x 1 root sys 28672 Jul 28 08:52 lpq
-r-xr-xr-x 1 root sys 28672 Jul 28 08:52 lpr
-r-xr-xr-x 1 root sys 24576 Jul 28 08:52 lprm
-rwxr-xr-x 1 root sys 4671 Jun 3 2008 lprsetup.sh
-r-sr-xr-x 1 root sys 40960 Jul 28 08:52 lpstat
Since I have a workaround now (/usr/bin/lp) I guess this is no longer urgent, but I would still like to get to the bottom of it.
09-19-2011 09:00 AM
I would guess that someone installed some freeware printing package in /usr/local/bin. Take a look at /usr/local/bin/lprsetup.sh to see if it offers any hints. My first reaction would be to remove/rename the /usr/local/bin versions of "lp" related files.
09-19-2011 09:20 AM
>restarted lpsched and tried again but still got the same error.
You might be able to use tusc to figure out what this /usr/local/bin/lp is trying to do and what files it is trying to access.
09-19-2011 01:28 PM
Apparently a Gostscript utility was installed and created the /usr/local/bin version of "lp" that doesn't work. HP-UX must look there before /usr/bin. Renaming the /usr/local/bin/lp tp lp.old fixed the issue. I attached the lprsetup.sh file just in case you where curious.
Thanks for the Help!!
09-19-2011 02:19 PM
The Ghostscript package itself does not normally include commands like "lp"
The text in the beginning of the lprsetup.sh script suggest the script may be intended as a driver solution for some printer that uses a parallel port connection.The script is intended for SunOS 4.1.3.
The DEVICES variable includes things like "bjt600.32" and "bjc600.32", which makes me think this is intended for some Canon inkjet printers. The script mentions a printcap file, so it's not at all suitable for HP-UX print spooler: the HP-UX spooler uses model scripts instead.
If you don't have a Canon BJC-600 or BJT-600 inkjet connected to your HP-UX, feel free to remove the superfluous print spooler commands from /usr/local/bin.
If you do have such a printer, someone may have used the SunOS driver solution as a source of raw material and information for writing a custom model script. See the "Models" paragraph of the lpadmin(1M) man page to understand how the model scripts work.