Bug 770 - smbd cannot cancel the UNIX print jobs
smbd cannot cancel the UNIX print jobs
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Printing
3.0.0
All All
: P4 normal
: none
Assigned To: Gerald (Jerry) Carter
:
Depends on:
Blocks: 807
  Show dependency treegraph
 
Reported: 2003-11-13 07:47 UTC by SATOH Fumiyasu
Modified: 2005-08-24 10:22 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SATOH Fumiyasu 2003-11-13 07:47:11 UTC
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]
...
Comment 1 SATOH Fumiyasu 2003-11-13 18:24:38 UTC
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: \>
Comment 2 SATOH Fumiyasu 2003-11-15 07:27:53 UTC
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));
 
Comment 3 SATOH Fumiyasu 2003-11-15 08:14:41 UTC
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.
Comment 4 SATOH Fumiyasu 2003-11-15 11:15:13 UTC
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;
Comment 5 Gerald (Jerry) Carter 2003-11-25 11:22:43 UTC
I don't think this patch is correct.  We should be sending the 
smb jobid back to the client and not the UNIX jobid.
Comment 6 Gerald (Jerry) Carter 2003-11-25 13:49:03 UTC
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?
Comment 7 Gerald (Jerry) Carter 2003-11-27 06:46:08 UTC
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 :) )
Comment 8 SATOH Fumiyasu 2003-11-27 07:28:16 UTC
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...
Comment 9 SATOH Fumiyasu 2003-11-27 07:35:22 UTC
This comment reply for Comment #5.

It's my error. Please ignore the patch in Comment #4.
Comment 10 Gerald (Jerry) Carter 2003-11-29 10:55:57 UTC
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.
Comment 11 Gerald (Jerry) Carter 2004-01-14 12:53:55 UTC
This should really be fixed now for 3.0.2rc1.
I finally figured out where the wrong jobid was 
being set.
Comment 12 Gerald (Jerry) Carter 2005-08-24 10:22:03 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.