Dear Friends:
We have an Alpha Server 2100 with two 250 processors, 256 Mbytes RAM and 8
GBytes in RAID 5
Array. We are running DU V3.2C ( Rev 148 ).
We run an application that generates a lot of statements daily that are
sent by lpr to print servers in our entire net. The problem arise at the
end of the month when around 4500-5000 statements are generated and we
realized that some of the statements are lost. We follow the mechanism and
ensure that the application passes the correct number of statements to unix
for printing.
The only way that we don't lose any job is if I stop the application before
the job number reachs 1000 ( I see that with the command "lpc status
<printer_name >"), wait for the queue to be empty and start the printing
in this remote printer.
I do this every month. :-(
The problem is when the job number is over 1000. I made a shell script
that send the a file to remote printer because I want to see was was wrong.
########################################################################
#!/sbin/sh
COUNT=0
while [ $COUNT != 2000 ]
do {
echo "Job number is $COUNT"
COUNT=`expr $COUNT + 1`
lpr -h -P remoto test_file
};
done
########################################################################
When the job number is over 1000 the system displays the following error
########################################################################
Job Number is 997
Job Number is 998
Job Number is 999
Job Number is 1000
lpr: cannot create /usr/spool/lpd20/dfA183bfibackup
Job Number is 1001
lpr: cannot create /usr/spool/lpd20/dfA184bfibackup
Job Number is 1002
lpr: cannot create /usr/spool/lpd20/dfA185bfibackup
Job Number is 1003
lpr: cannot create /usr/spool/lpd20/dfA186bfibackup
Job Number is 1004
lpr: cannot create /usr/spool/lpd20/dfA187bfibackup
Job Number is 1005
lpr: cannot create /usr/spool/lpd20/dfA188bfibackup
Job Number is 1006
lpr: cannot create /usr/spool/lpd20/dfA189bfibackup
Job Number is 1007
lpr: cannot create /usr/spool/lpd20/dfA190bfibackup
Job Number is 1008
lpr: cannot create /usr/spool/lpd20/dfA191bfibackup
And automatically the queue becomes to decrease, the jobs is lost too.
In few words
1. The printer lose the statement intermittently,
2. The majority of the statement file size is roughly 6 Kbytes.
3. The disk space is enough. The spool directory is located in the "/usr"
filesystem.
This filesystem is configured with 2 Gbytes for data storage. This is the
output
of df command.
df -k
Filesystem 1024-blocks Used Avail Capacity Mounted on
/dev/re0a 96079 52825 33646 61% /
/proc 0 0 0 100% /proc
/dev/re0g 2034671 1178232 652971 64% /usr
/dev/re0h 4826573 3377501 966414 78% /u1
If one statement is aprox. 6 Kbytes, in the worst case, we will print 5000
statements and the disk space occupied by all jobs to be printed will be ~
30 Mbytes.
4. I use a print server configured with the TCP/IP suite of protocols.
A copy of "/etc/printcap" is supplied.
axis|main_print_server-pr| Network printer on Print server
main_print_server:\
:lp=:\
:sd=/var/spool/lpd/main_print_server-pr:\
:lf=/var/spool/lpd/main_print_server-pr/log:\
:rm=main_print_server:\
:rp=pr1:
5. The situation happened when print jobs exceeded 1000 in the queue.
6. We use the Digital command "lprsetup" because is very ease the process
for setup a printer. In all ours cases, all the printer are remote and
two parameters needs lprsetup for configuring this type of printer.
Rm : Remote system ( found in /etc/hosts )
Rp : Remote printer ( the name of the queue in the print server )
We use the default values for the rest of the options.
I think the maximum number of jobs lpr can control up to 1000 but how can
we
overcome this limitation. Today, in the world, there are several unix
applications that send more than 1000 jobs to be printed.
I revised the lpr man page ( and all entries in /etc/printcap ) and there
are not any parameter in relation with the job's number.
Do you know if there is any kernel configuration parameter for controlling
the number of the lpr queue?
Thanks in advance for the cooperation I'm sure you will give to this matter
Abdon Tremols
Received on Fri May 23 1997 - 21:36:53 NZST