Printing problem

[Machaya Chivaviro_1]

I am running HP-UX 9000. With version 11.0. I have about 200 printer configured and I use Ice-tcp product which is loaded on windows or Dos terminals.
The problem started today when all printers started not printing. I booted the server but did not help and on trying to print I got this error after A long wait.

/ :># lp -dprinter12 /etc/profile
request id printer12-178 failed to enqueue

What is the cause of this problem.

[A. Clay Stephenson]

Probably the first thing you should try is an lpshut followed by lpsched to restart the scheduler.

[A. Clay Stephenson]

Also, after you do the lpshut, you should cd to /var/spool/lp. Look for the files SCSHEDLOCK and FIFO; if found, remove the\m, and trhen do the lpsched.

[A. Clay Stephenson]

One last thought, you can ping printer12 can't you?

[PIYUSH D. PATEL]

Hi,

Do the following.

#lpshut
# rm /var/spool/lp/FIFO
# rm /var/spool/lp/SCHEDLOCK

Remove /var/spool/lp/tmplock if it exists

#/usr/sbin/lpsched

Check the file Permissions

/usr/sbin/lpsched (-r-sr-xr-x root:bin)
/var/spool/lp (drwxr-xr-x lp:bin)

What is the output of lpstat -t command ???

Piyush

[Machaya Chivaviro_1]

Have tried it but gives the same problem. I do not know if there can be missing files. All interface files are there and works well as I have tested them

device for br25man: /dev/null
device for br25oc: /dev/null
device for br25rc: /dev/null
device for br26man: /dev/null
device for br26oc: /dev/null
device for br26rc: /dev/null
device for br27man: /dev/null
device for br27oc: /dev/null
device for br27rc: /dev/null
device for br28man: /dev/null
device for br28oc: /dev/null
device for br28rc: /dev/null
device for br29man: /dev/null
device for br29oc: /dev/null
device for br29rc: /dev/null
device for br30bo: /dev/null
device for br30dc: /dev/null
device for br30man: /dev/null

br19bo accepting requests since Jun 30 08:12
br19dc accepting requests since Jun 30 08:12
br19eq accepting requests since Jun 30 08:12
br19rc accepting requests since Jun 30 08:12
br20man accepting requests since Jun 30 08:12
br20oc accepting requests since Jun 30 08:12
br20rc accepting requests since Jun 30 08:12
br21dc accepting requests since Jun 30 08:12
br21man accepting requests since Jun 30 08:12
br21oc accepting requests since Jun 30 08:12
br21rc accepting requests since Jun 30 08:12
br22man accepting requests since Jun 30 08:12
br22oc accepting requests since Jun 30 08:12
br22rc accepting requests since Jun 30 08:12

[Machaya Chivaviro_1]

I also have many processes being started by and run by lpsched once it stats running is there a max number of processes for this where it is configured. Is this suppose to be the case.
another error - The fork function failed. Too many processes already exist.

lp -dhelpdesk rep
lp: can't open file rep

The file is there with all permissions

/u/chivavir :$ ll rep
-rwxrwxrwx 1 chivavir computers 18501 Jun 1 00:51 rep
/u/chivavir :$ lp -dhelpdesk rep
lp: can't open file rep
/u/chivavir :$ ll rep
-rwxrwxrwx 1 chivavir computers 18501 Jun 1 00:51 rep
/u/chivavir :$

[Thayanidhi]

Just for above error (fork failed cannot create process) the process table is full.

You should tune your kernel to increase the NPROC.

[Thayanidhi]

I suggest you not to modify NPROC instead modify the MAXUSERS value, and use the original formulas for the rest of the values.

[Steve Steel]

Hi

This is certainly tuning but not so much NPROC as MAXUPRC

Each print job can spawn upto 4 processes and they are all user lp.

MAXUPRC is the maximum number of processes which a single user may take.

This and nproc can go up.

If you have a lot of problems always think
about a disable of a few printers until the others finish printing and then enable them again.


Steve Steel

[Steve Steel]

Hi

make sure you have

PHCO_25110: s700_800 11.00 lpspool subsystem cumulative patch



On your box


steve Steel

[Rita C Workman]

Just to add one other thing..
I noticed it said it couldn't open a file. You might want to double check your nfile parm. See if there are any nfile messages in your syslog.

Just a thought,
Rita