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
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
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.
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 ?
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.
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.
Eric, please attach the problematic smb.conf to this report. Thanks.
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.
This is ok in 3.0.11 with all of print print_queue_update() fixed. Tested against Version 3.0.12pre2-SVN-build-5657
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.