The smbd cannot cancel the print jobs. I'v tested the smbd 3.0.0 from the smbclient 3.0.0 and 2.2.8a. $ lpr sugar.fns $ lpq ipsio-miracle is ready and printing Rank Owner Job File(s) Total Size active fumiya 34 sugar.fns 1024 bytes $ smbclient //localhost/test -Ufumiya%pass smb: \> queue 1 1024 sugar.fns smb: \> cancel 1 Job 1 cancelled smb: \> queue 1 1024 sugar.fns smb: \> testparam -s -v: ... printing = bsd print command = lpr -r -P'%p' %s lpq command = lpq -P'%p' lprm command = lprm -P'%p' %j ... smbd's level 10 log (smbd does not call the lprm command): ... Got API command 81 of form <W> <> (tdscnt=0,tpscnt=7,mdrcnt=65535,mprcnt=1024) Doing RDosPrintJobDel rap_to_pjobid called. rap_to_pjobid: jobid 34 maps to RAP jobid 1 copy_trans_params_and_data: params[0..4] data[0..0] ...
The print jobs queuing from client can be cancel, but client gets strange error: $ smbclient //localhost/test -Ufumiya%pass smb: \> queue smb: \> print load.c putting file load.c as load.c (3.6 kb/s) (average 3.6 kb/s) smb: \> queue 2 2076 Remote Downlevel Document load.c smb: \> cancel 2 Error cancelling job 2 : NT_STATUS_OK smb: \> queue smb: \>
Here is a patch for fixing a problem that the UNIX print job is marked as SMB print job if the UNIX print job was already stored in var/locks/printing/<printername>.tdb. But this patch does NOT fix this bug (Bug 770). Index: source/printing/printing.c =================================================================== RCS file: /cvsroot/samba/source/printing/printing.c,v retrieving revision 1.139.2.39 diff -u -r1.139.2.39 printing.c --- source/printing/printing.c 13 Nov 2003 20:15:16 -0000 1.139.2.39 +++ source/printing/printing.c 15 Nov 2003 15:13:09 -0000 @@ -613,12 +613,14 @@ pj.status = q->status; pj.size = q->size; pj.spooled = True; - pj.smbjob = (old_pj != NULL ? True : False); fstrcpy(pj.filename, old_pj ? old_pj->filename : ""); - if (jobid < UNIX_JOB_START) + if (jobid < UNIX_JOB_START) { + pj.smbjob = (old_pj != NULL ? True : False); fstrcpy(pj.jobname, old_pj ? old_pj->jobname : "Remote Downlevel Document"); - else + } else { + pj.smbjob = False; fstrcpy(pj.jobname, old_pj ? old_pj->jobname : q->fs_file); + } fstrcpy(pj.user, old_pj ? old_pj->user : q->fs_user); fstrcpy(pj.queuename, old_pj ? old_pj->queuename : lp_const_servicename(snum));
Hmmm... If you apply the patch included in 'Additional Comment #2 for Bug 770', you cannot cancel the print jobs anymore. ... The smbd uses the print_queue_status() to get a printer queue (print jobs) listing. This job information has a print 'sysjob' id (UNIX print jobid), not a 'SMB' jobid. Then the smbd shows 'sysjob' ids to a SMB client. On the other hand, The smbd receives a print jobid ('sysjob' id) from a client and calls the print_job_delete() with the 'sysjob' id to delete a print job. But the print_job_*() takes a 'SMB' jobid, not a 'sysjob' id. That is why the smbd cannot handle queued print jobs.
I had forgotten posting another patch. Sorry... --- /home/fumiya/factory/samba/org/samba/source/printing/printing.c 2003-11-16 00:12:36.000000000 +0900 +++ source/printing/printing.c 2003-11-16 04:09:35.000000000 +0900 @@ -720,7 +719,7 @@ } /* Save the pjob attributes we will store. */ - ts->queue[i].job = jobid; + ts->queue[i].job = pjob.sysjob; ts->queue[i].size = pjob.size; ts->queue[i].page_count = pjob.page_count; ts->queue[i].status = pjob.status; @@ -2182,7 +2181,7 @@ continue; } - queue[total_count].job = jobid; + queue[total_count].job = pjob->sysjob; queue[total_count].size = pjob->size; queue[total_count].page_count = pjob->page_count; queue[total_count].status = pjob->status;
I don't think this patch is correct. We should be sending the smb jobid back to the client and not the UNIX jobid.
ok. After spending some time on this, i don't see wherethe patch in comment #2 is needed. Can you explain to me how you gor there? when a UNIX job is first read and stored in the queue.tdb, we store its name. After that, it has an smbjobid. And regarding the original bug report -- I have successful canceled jobs using lprng and cups printing backends. I'm pretty sure this is going to come down to some configuration issue. What server OS is this?
Ahh....ok. That makes more sense (can't cancel UNIX print jobs). What printing backend are you using ? And what server OS (assuming linux based on your email :) )
This comment is reply for Comment #6 and #7. PC: DELL Latitude X200 (Pentium III) OS: Debian GNU/Linux unstable (sid) CC: gcc 3.3.2, 2.95 Samba: 3.0.0, 3.0.1pre3 configure options: --with-ldap --with-ldapsam --with-pam --with-pam_smbpass \ --with-acl-support --with-winbind --with-syslog \ --with-utmp --with-smbwrapper --with-smbmount --with-libsmbclient smb.conf (no [global] and other sections): [test] printer name = ipsio-miracle printable = yes guest ok = yes testparam -v -s: printing = bsd print command = lpr -r -P'%p' %s lpq command = lpq -P'%p' lprm command = lprm -P'%p' %j lppause command = lpresume command = queuepause command = queueresume command = ------------------------------------------------------------- Procedure: 1. Check if the print queue is empty: $ lpq ipsio-miracle is not ready no entries 2. Connect to the print share: $ smbclient //127.0.0.1/test -Ufumiya 3. Check if <queue>.tdb has no jobid: # tdbdump /usr/local/samba/var/locks/printing/test.tdb |\ grep key |grep -v / (Output is nothing ... It's OK!) 4. Print a file by lpr command: $ lpr foo.ps $ lpq ipsio-miracle is not ready Rank Owner Job File(s) Total Size 1st fumiya 91 foo.ps 17408 bytes 5. Check if the UNIX job is shown by smbclient: smb: \> queue 1 17408 foo.ps 6. Check if <queue>.tdb has a UNIX print job's SMB jobid: # tdbdump /usr/local/samba/var/locks/printing/test.tdb |\ grep key |grep -v / key = "k'\00\00" UNIX_JOB_START + UNIX jobid (sysjob) = 10000 + 91 = 0x27 (') 0x6B (k) 7. Wait 'lpq cache time' seconds (default 10 sec). 8. Check if the UNIX job is shown by smbclient (again): smb: \> queue 1 17408 foo.ps 9. Check if <queue>.tdb has a UNIX print job's SMB jobid (again): # tdbdump /usr/local/samba/var/locks/printing/test.tdb |\ grep key |grep -v / (There is no jobid ... Why?) If you apply the Comment #2 patch, this problem is gone. NOTE: Bug 770 does NOT depend on this problem. 10. Try to cancel the UNIX print job from smbclient: smb: \> cancel 1 Job 1 cancelled 11. Check if the UNIX was canceled: smb: \> queue 1 17408 foo.ps $ lpq ipsio-miracle is not ready Rank Owner Job File(s) Total Size 1st fumiya 91 foo.ps 17408 bytes Canceling failed. ------------------------------------------------------------- Level 10 log info: $ cat -n /usr/local/samba/var/log.smbd |egrep '(_to_(rap|pjob)|Job)' 718 Doing WPrintJobEnumerate 719 [2003/11/27 23:20:43, 3] smbd/lanman.c:api_WPrintJobEnumerate(3000) 720 WPrintJobEnumerate uLevel=2 name=test 750 [2003/11/27 23:20:43, 10] printing/printing.c:pjobid_to_rap(58) 751 pjobid_to_rap: called. 752 [2003/11/27 23:20:43, 10] printing/printing.c:pjobid_to_rap(93) 753 pjobid_to_rap: created jobid 91 maps to RAP jobid 1 754 [2003/11/27 23:20:43, 4] smbd/lanman.c:api_WPrintJobEnumerate(3042) 755 WPrintJobEnumerate: errorcode 0 844 Doing RDosPrintJobDel 845 [2003/11/27 23:20:44, 10] printing/printing.c:rap_to_pjobid(101) 846 rap_to_pjobid called. 847 [2003/11/27 23:20:44, 10] printing/printing.c:rap_to_pjobid(114) 848 rap_to_pjobid: jobid 91 maps to RAP jobid 1 The line 753 seems that smbd notified the client of RAP jobid 1 that was mapped from the UNIX print jobid 91, not the SMB jobid 10091!. The line 848 seems that smbd received RAP jobid 1, got SMB(?) jobid 91 and checked if SMB(?) jobid 91 is stored in queue by using print_job_exists(snum, jobid). Because the SMB jobid 91 does not exist in queue (but the SMB jobid 10091 exists), print_job_exists returned False. The line 848 was generated at smbd/lanman.c: static BOOL api_RDosPrintJobDel(...snip...) ...snip... if(!rap_to_pjobid(SVAL(p,0),&snum,&jobid)) return False; /* check it's a supported varient */ if (!(strcsequal(str1,"W") && strcsequal(str2,""))) return(False); *rparam_len = 4; *rparam = REALLOC(*rparam,*rparam_len); *rdata_len = 0; if (!print_job_exists(snum, jobid)) { errcode = NERR_JobNotFound; goto out; } ...snip...
This comment reply for Comment #5. It's my error. Please ignore the patch in Comment #4.
ok. I'll agree with the patch in comment #2 now. Thanks for helping me to understand what the problem was. Checking the fix in.
This should really be fixed now for 3.0.2rc1. I finally figured out where the wrong jobid was being set.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.