Bug 1783 - MAX PRINT JOBS parameter is not effective.
MAX PRINT JOBS parameter is not effective.
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Printing
3.0.7
All Windows XP
: P3 normal
: none
Assigned To: Gerald (Jerry) Carter
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-16 13:09 UTC by Eric Talbot
Modified: 2005-08-24 10:17 UTC (History)
0 users

See Also:


Attachments
SMB.CONF of a server having this issue (2.13 KB, text/plain)
2004-10-21 12:36 UTC, Eric Talbot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Talbot 2004-09-16 13:09:57 UTC
My smb.conf file contains in the general section. 

max print jobs = 50 

And i disabled the print queue using this command : 

disable PrintQueueName

Therefore i would expect SAMBA to reject print jobs after the 50th. 
But in real life it does not, it continues to spool indefinitely.


If i run a batch file from a client workstation to print continuously. It 
means the request to print is made much faster than manually. It will stop 
when 7 jobs are spooled in the print queue ??!?!?!?

Running smbd -i -F -S - - debuglevel=3 returns the following error message 
on the linux console when 7 jobs are spooled in the print queue: 

print_job_start: Queue p13113 number of jobs (51) larger than max 
printjobs per queue (50) 
error string = no space left on device 
error packet at smbd/reply.c(3041) cmd=192 (SMBsplopen) 
NT_STATUS_DISK_FULL 

but there's only 7 jobs in the queue.

Release 3.0.7 does not fix this 


It seems to be an issue in the way Samba calculate the number of jobs that 
are in the print queue ? 

The reason why i am testing this is because one of my customer prints A 
LOT ( over 2 thousands jobs per day ) and his users gets exactly this 
problem when lots of people are trying to print at the same time. Default 
value of max print jobs is 1000 setting this to 0 ( to permit any number 
of print jobs ) does not fix the issue. At one point even if this parameter 
is set to 0, the server stops accepting new print jobs. Note that in my real 
problem, the default value should let us spool 1000 documents in the queue but 
when the users have this issue ( i mean the server refuses to jobs to print ) 
there is only a few documents in the queue.



--------->RESOLUTION 
I was able to bypass the max print jobs = 50 parameter by putting the 
lines 2057 to 2061 in comments of the source/printing.c file. In this 
manner there's no comparison made on the number of job in the print queue 
and this parameter.

My guess is that a wrong number of jobs actually in the queue is reported. 


Eric.TAlbot@canammanac.com
or 
Rick.Talbot@canammanac.com
Comment 1 Eric Talbot 2004-09-17 10:32:41 UTC
Additional diagnostics comments 
1- Using version 3.07
2- Using the parameter MAX PRINT JOBS = 0 in smb.conf
3- AND I DID NOT TOUCH the source code

I reproduce an heavily loaded server by using batch file that continuously
prints using the command copy filename lpt1 ( of course lpt1 points to a print
queue on the linux and the filename is a printjob i created ) The print queue
accept new job but does not print anything ( i used : disable printqueue).

This batch file runs on 3 different computer at the same time. 
At one point when there's more than 2000 documents in the queue the batch file
begins to say there's not enough space on the disk, looking at the log of this
particular workstation, ( debuglevel=3 ) i have : 

[2005/09/17 13:15:24, 0] printing/printing.c:allocate_print_jobid(1960)
  allocate_print_jobid: failed to allocate a print job for queue p13113
[2005/09/17 13:15:24, 3] printing/printing.c:print_job_start(2130)
  print_job_start: returning fail. Error = No space left on device
[2005/09/17 13:15:24, 3] smbd/error.c:error_packet(105)
  error string = No space left on device
[2005/09/17 13:15:24, 3] smbd/error.c:error_packet(129)
  error packet at smbd/reply.c(3053) cmd=192 (SMBsplopen) NT_STATUS_DISK_FULL

and sometimes : 
[2005/09/17 13:15:24, 3] smbd/error.c:error_packet(129)
  error packet at smbd/trans2.c(3017) cmd=50 (SMBtrans2) NT_STATUS_OBJECT_PATH_N
OT_FOUND
Comment 2 Eric Talbot 2004-09-17 11:02:45 UTC
Additional diagnostics comments PART 2 
1- Using version 3.07
2- Using the parameter MAX PRINT JOBS = 0 in smb.conf
3- AND I DID NOT TOUCH the source code

I found another thing in the logs 

[2005/09/17 13:59:18, 3] printing/printing.c:print_job_start(2058)
  print_job_start: Queue p13113 number of jobs (10000) larger than max printjobs
 per queue (9999).
[2005/09/17 13:59:18, 3] smbd/error.c:error_packet(105)
  error string = No space left on device
[2005/09/17 13:59:18, 3] smbd/error.c:error_packet(129)
  error packet at smbd/reply.c(3053) cmd=192 (SMBsplopen) NT_STATUS_DISK_FULL

It basically says there's more that 9999 documents in the queue but the command
lpq report 3328 documents actually spooled. There's definitely a problem in the
way that samba calculates its print jobs.

Comment 3 Eric Talbot 2004-09-17 11:37:25 UTC
Additional diagnostics comments 
1- Using version 3.07
2- Using the parameter MAX PRINT JOBS = 0 in smb.conf
3- MODIFIED /SAMBA-3.0.7/SOURCE/PRINTING/PRINTING.C , i've placed a comment (//)
in front of the lines 2040, 2041, 2042, 2043 and 2057, 2058, 2059, 2060, 2061.

The behavior is quite different this time. I've spooled over 5500 documents but
when about 4000 documents are spooled it begins to reject a few job arbitrarily
and the only trace i find in the logs is this : 

[2005/09/17 14:26:03, 3] smbd/error.c:error_packet(129)
  error packet at smbd/trans2.c(3017) cmd=50 (SMBtrans2) NT_STATUS_OBJECT_PATH_N
OT_FOUND



WHAT IS MUST DO IS : 
1. BEING ABLE TO SPOOL AS MANY DOCUMENTS AS NEEDED AND VERY RAPIDLY
2. IN THE MEAN TIME ,, SINCE AN OFFICE HAVING MORE THAN 200 USERS ARE HAVING
DAILY PROBLEMS WITH THIS ,, I NEED TO KNOW IF I PUT A COMMENTS ON THE LINES
MENTIONNED ABOVE I CAN POTENTIALLY CREATE OTHER PROBLEMS.

When this problem ARISE , any other user trying to print will have the issue
even if i deleted all the documents in the queue. I mean they are still having
printing issue. I have to restart samba and this is unacceptable. IS THERE A WAY
I COULD REFRESH SMBD WITH THE RIGHT NUMBER OF DOCUMENTS WITHOUT RESTARTING ,,
DELTING A CACHE FILE OR SOMETHING ? 

Comment 4 Gerald (Jerry) Carter 2004-10-19 09:46:06 UTC
could you try the (slightly largish) patch at
http://www.samba.org/~jerry/patches/post-3.0.7/printername_and_queue_update.patch
?

It does 2 things:

(a) fixes bug 1519, and
(b) fixes the problems with the print queue listing now being updated.

I've a hunch that (b) will fix the max print jobs as well.
Please reopen if the patch doesn't fix th bug.
Comment 5 Gerald (Jerry) Carter 2004-10-20 08:57:02 UTC
Reopening.  Looks like we are not wuite done here....

comments from Eric:

> The patch fix the upper limit. I mean we can spool up 
> to 15000 document in the print queue. That is what i did 
> in order to test it.
>
> If however we try to use the MAX PRINT JOB = 100 ( for 
> example ) in  smb.conf. The behavior is the same 
> as before. It does stop after a few  documents are 
> spooled in the queue and a second later it restart again 
> to  spool document  and continue like this for good. 
> It does bypass the limit provided by MAX PRINT JOB. 
> 
> As far as i am concerned the MAX PRINT JOB 
> parameter could always be 0. I  do not restrict 
> users to a certain number of print jobs in the queue.
Comment 6 Gerald (Jerry) Carter 2004-10-20 08:59:31 UTC
Eric, please attach the problematic smb.conf to this report.  Thanks.
Comment 7 Eric Talbot 2004-10-21 12:36:11 UTC
Created attachment 739 [details]
SMB.CONF of a server having this issue

As you will see i use cups for printing.
My /etc/cups/cupsd.conf has the parameter MaxJob = 0. Meaning we can spool as
many documents as we want in there.
Comment 8 Gerald (Jerry) Carter 2005-03-07 16:05:34 UTC
This is ok in 3.0.11 with all of print print_queue_update() 
fixed. Tested against Version 3.0.12pre2-SVN-build-5657
Comment 9 Gerald (Jerry) Carter 2005-08-24 10:17:31 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.