Bug 106177 - Samba spoolss notify not working
Samba spoolss notify not working
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: samba (Show other bugs)
3.0
s390 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-03 10:26 EDT by Daniel Jarboe
Modified: 2014-08-31 19:25 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-24 10:31:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Refreshing print share window... no jobs being displayed (36.48 KB, text/plain)
2003-10-03 10:35 EDT, Daniel Jarboe
no flags Details

  None (edit)
Description Daniel Jarboe 2003-10-03 10:26:32 EDT
Description of problem:
Samba 3 / cups print-server on a remote subnet.  The # of documents waiting to 
be printed according to the windows "printers" folder is 0 when there are 
documents waiting to be printed.  Also, the print share typically fails to show 
jobs waiting when refreshed.  In the 10 log there messages indicating 
rpc_parse/parse_prs.c errors, but I don't know if they are related.

Version-Release number of selected component (if applicable):
samba-3.0.0-12rc4.3E

How reproducible:
Always

Steps to Reproduce:
1. Pause cups printer or class that a samba print share is pointing to.
2. Submit a job from windows client.
3. Open the "printers" folder for samba... Documents will be 0 even though 
there is one document waiting.  Refreshing doesn't help.
4. Double click on the printer share from the printers folder.  Documents are 
often not shown, and refreshing is unreliable.  lpq -a or lpq -Pprinter_name on 
the server shows documents waiting.
    
Actual results:
0 documents shown under printers folder
documents shown when viewing individual printer share unreliable ... often none 
shown.

Expected results:
1 document shown under printers folder
1 document reliably shown when viewing individual printer share, with and 
without refreshes.

Additional info:
and lpq cache time = 1 somewhat helps the 2nd part of the problem, but it's 
still buggy.

In the last batch of tests AFICIO_5_E is a class with one printer in it.  I 
paused the class.

# lpq -PAFICIO_5_E
AFICIO_5_E is not ready
Rank    Owner   Job     File(s)                         Total Size
1st     jarboed 85      RUMBA Document                  30720 bytes

smb.conf:
[global]
        workgroup = TCS_MAIN_DOM
        netbios name = LINPS2
        server string = Samba 3 server on linps2
        interfaces = eth0 127.0.0.1/24
        bind interfaces only = yes
        security = DOMAIN
        encrypt passwords = Yes
        password server = tcs_main_pdc
        username map = /etc/samba/smbusers
        log level = 10
        log file = /var/log/samba/%m.log
        mangling method = hash2
        preferred master = No
        domain master = No
        local master = No
        dns proxy = No
        wins server = tcs_main_pdc
        kernel oplocks = No
        winbind uid = 10000-20000
        winbind gid = 10000-20000
        winbind use default domain = yes
        winbind enum users = yes
        winbind enum groups = yes
        printing = cups
        printcap name = cups
        blocking locks = No
        locking = No
        oplocks = No
        level2 oplocks = No
        guest account = nobody
        load printers = no
        # announce to local master... can't broadcast to it
        remote announce = 10.176.137.7
[printers]
        comment = All Printers
        path = /var/spool/samba
        public = yes
        guest ok = yes
        writable = no
        printable = yes
[print$]
        path = /etc/samba/drivers/
[AFICIO_5_E]
        path = /var/spool/samba
        printer = AFICIO_5_E
        printable = yes


cups's classes.conf:
# Class configuration file for CUPS v1.1.17
# Written by cupsd on Fri 03 Oct 2003 01:11:00 PM GMT
<Class AFICIO_5_E>
State Stopped
StateMessage Paused
Accepting Yes
JobSheets tcs none
Printer AFICIO_5_E_printer
QuotaPeriod 0
PageLimit 0
KLimit 0
</Class>
<Class AFICIO_5_W>
State Idle
Accepting Yes
JobSheets none none
Printer AFICIO_5_W_printer
QuotaPeriod 0
PageLimit 0
KLimit 0
</Class>

cups's printers.conf:
# Printer configuration file for CUPS v1.1.17
# Written by cupsd on Fri 03 Oct 2003 01:10:07 PM GMT
<DefaultPrinter AFICIO_5_E_printer>
DeviceURI lpd://172.16.45.122/AFICIO_5_E_printer
State Idle
Accepting Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
</Printer>
<Printer AFICIO_5_W_printer>
DeviceURI lpd://10.176.155.241/AFICIO_5_W_printer
State Idle
Accepting Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
</Printer>

I will attempt to add level 10 logs as attachments...
Comment 1 Daniel Jarboe 2003-10-03 10:35:35 EDT
Created attachment 94913 [details]
Refreshing print share window... no jobs being displayed
Comment 2 Daniel Jarboe 2003-10-03 10:48:10 EDT
Clarification:
The first line of actual results "0 documents shown under printers folder" will 
match expected results "1 document shown under printers folder" when lpq cache 
time >= 10 in smb.conf (default = 10)... but that causes the second line of 
actual results "documents shown when viewing individual printer share 
unreliable ... often none shown." to not match expected results.  In order for 
for the individual print share documents to kind of show up pseudo-reliably 
after refreshes, lpq cache time has to be really small, like 1, but then that 
causes a problem with the first part.


Taking out lpq cache time causes the first line of actual results to match 
expected results...

appears to be working for me now (expected results: 1 documents shown under 
printers folder) so this part is not "Always" reproducable... but the second 
part: documents shown when viewing individual printer share unreliable ... 
often none shown is still having problems.
Comment 3 Jay Fenlason 2005-05-23 12:16:44 EDT
This was probably fixed by one of the many printing fixes between 3.0.0rc4 and 
now.  Is it still a problem? 
Comment 4 Daniel Jarboe 2005-05-24 07:11:46 EDT
It is no longer a problem, thanks.

Note You need to log in before you can comment on or make changes to this bug.