Testing upgrade of Print Servers from Samba-2.2.8a to Samba-3.0.1 on SuSE SLES8 (s390 Arch). Samba is joined as a member of an NT4 domain (so using winbindd) and configured to offer up W2K print drivers via the print$ share, with approximately 130 printers and 35 different print drivers defined. When attempting to change printer properties via the Windows Printer Properties (I'm using a Win XP Client) the associated smbd process appears to loop (using lots of CPU) and leak memory. Depending on the speed of your environment and how much virt memory available this can exhaust the available memory in a few minutes. Since seeing this on a client machine I've been able to reproduce using a similar Linux configuration running under the Hercules s390 emulator on my Athlon machine. Unfortunately, for some reason I've not been able to replicate the same problem under i386. I know s390 playpens can be hard to come by so am happy to provide access to what I've already got here running under Herc. It's not a great place to compile stuff due to the emulation overhead. Even with distcc and ccache installed it's still real slow. At this point the only real diagnostic data I've obtained has been from log.smbd at debuglevel 3 and a tcpdump sniff. While the thing loops and the storage grows the following is repeated within the log: [2004/04/22 09:54:16, 3] smbd/process.c:process_smb(890) Transaction 17561 of length 168 [2004/04/22 09:54:16, 3] smbd/process.c:switch_message(685) switch message SMBtrans (pid 5525) [2004/04/22 09:54:16, 3] smbd/ipc.c:reply_trans(538) trans <\PIPE\> data=80 params=0 setup=2 [2004/04/22 09:54:16, 3] smbd/ipc.c:named_pipe(334) named pipe command on <> name [2004/04/22 09:54:16, 3] smbd/ipc.c:api_fd_reply(296) Got API command 0x26 on pipe "spoolss" (pnum 71d5)free_pipe_context: destroying talloc pool of size 0 [2004/04/22 09:54:16, 3] rpc_server/srv_pipe.c:api_rpcTNP(1509) api_rpcTNP: rpc command: SPOOLSS_GETPRINTERDATA [2004/04/22 09:54:16, 3] rpc_server/srv_pipe_hnd.c:free_pipe_context(544) free_pipe_context: destroying talloc pool of size 22 [2004/04/22 09:54:16, 3] smbd/process.c:process_smb(890) Transaction 17562 of length 168 [2004/04/22 09:54:16, 3] smbd/process.c:switch_message(685) switch message SMBtrans (pid 5525) [2004/04/22 09:54:16, 3] smbd/ipc.c:reply_trans(538) trans <\PIPE\> data=80 params=0 setup=2 [2004/04/22 09:54:16, 3] smbd/ipc.c:named_pipe(334) named pipe command on <> name [2004/04/22 09:54:16, 3] smbd/ipc.c:api_fd_reply(296) Got API command 0x26 on pipe "spoolss" (pnum 71d6)free_pipe_context: destroying talloc pool of size 0 [2004/04/22 09:54:16, 3] rpc_server/srv_pipe.c:api_rpcTNP(1509) api_rpcTNP: rpc command: SPOOLSS_GETPRINTERDATA [2004/04/22 09:54:16, 3] rpc_server/srv_pipe_hnd.c:free_pipe_context(544) free_pipe_context: destroying talloc pool of size 22 From my sniff of packets i get a tonne of the following: 45 0.872772 192.168.200.3 -> 10.250.0.217 TCP netbios-ssn > 1388 [ACK] Seq=2080 Ack=3360 Win=9681 Len=0 46 0.903968 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11993 ctx_id: 0 47 0.906787 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12001 opnum: 26 ctx_id: 0 48 0.938085 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11994 ctx_id: 0 49 0.938988 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12002 opnum: 26 ctx_id: 0 50 0.940409 192.168.200.3 -> 10.250.0.217 TCP netbios-ssn > 1388 [ACK] Seq=2288 Ack=3696 Win=9681 Len=0 51 0.960093 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11995 ctx_id: 0 52 0.960824 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12003 opnum: 26 ctx_id: 0 53 0.980585 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11996 ctx_id: 0 54 0.981668 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12004 opnum: 26 ctx_id: 0 55 1.003580 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11997 ctx_id: 0 56 1.004887 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12005 opnum: 26 ctx_id: 0 57 1.023244 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11998 ctx_id: 0 58 1.024355 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12006 opnum: 26 ctx_id: 0 59 1.059648 192.168.200.3 -> 10.250.0.217 TCP netbios-ssn > 1388 [ACK] Seq=2704 Ack=4368 Win=9681 Len=0 To re-create on s390 here's some additional info you're probably going to need: Distrib: SuSE SLES8: Kernel 2.4.21-102-default glibc: glibc-2.2.5-115 lprng: lprng-3.8.12-50 (havn't tried CUPS in this envr) Samba: * Have used the RPMS from ftp://ftp.suse.com/pub/people/gd/samba3/sles8-s390/samba3-3.0.1, however have seen similar problems when built from stable source tree. sles81:/etc # rpm -qa |grep -i samba samba3-3.0.1-0 samba3-client-3.0.1-0 samba3-doc-3.0.1-0 samba3-winbind-3.0.1-0 I can fairly consistently re-create the stg leak from Win XP by performing the following. However the problem doesn't always occur at the same point each time. Sometime it doesn't actually occur every time, but more often that not if I follow this sequence it will occur at some point: In XP do a Start -> Run -> \\sles81 Double click on Q941 to install and load driver (printcap entry detailed below) Once installed select properties of Q941 from local XP printers folder and change say the orientation in the 'Printing Preferences'. Q941 is defined in printcap on my test envr as follows: # Lexmark Optra S 1250 - Q941 Q941 :lp=/dev/null :rp=PASS :sd=/var/spool/lpd/%P As u can see by the comment it has the Lexmark S 1250 driver assigned. I suspect this may be more reproducible with the large number of drivers/printers we have defined. If needed I could forward all of the tdb files and the contents of the printers dir. A tdbbackup -v reveals no tdb problems. /etc/samba/smb.conf # Global parameters [global] workgroup = DBR05A netbios name = SLES81 server string = Samba Printserver for Testing os level = 65 domain master = no domain logons = no preferred master = auto local master = yes wins server = 10.250.0.150 security = DOMAIN encrypt passwords = yes password server = gollum max log size = 10000 log level = 3 syslog = no socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192 max xmit = 65536 dns proxy = No map to guest = never guest account = nobody winbind uid = 10000-20000 winbind gid = 10000-20000 winbind separator = + printing = lprng printer admin = @DBR05A+"Print Admin Priv S3",@DBR05A+"Domain Admins",DBR05A+grantb # # Start of the default options for defined shares # browseable = yes read only = no guest ok = no # posix locking = no create mask = 0770 dns proxy = No map to guest = never guest account = nobody winbind uid = 10000-20000 winbind gid = 10000-20000 winbind separator = + printing = lprng printer admin = @DBR05A+"Print Admin Priv S3",@DBR05A+"Domain Admins",DBR05A+grantb # # Start of the default options for defined shares # browseable = yes read only = no guest ok = no # posix locking = no create mask = 0770 directory mask = 0770 [homes] path = /home/smbshare/%U comment = Home Directory for %U on %L browseable = no [print$] path = /etc/samba/printers guest ok = no read only = yes write list = @DBR05A+"Print Admin Priv S3",@DBR05A+"Domain Admins",DBR05A+grantb admin users = @DBR05A+"Print Admin Priv S3",@DBR05A+"Domain Admins",DBR05A+grantb create mask = 0664 directory mask = 0775 force group = +root posix locking = no [printers] path = /var/spool/samba printable = yes browseable = yes guest ok = no printing = lprng # use client driver = yes # default devmode = yes print command = /usr/bin/lpr -U%U@%M -P%p -r %s lpq command = /usr/bin/lpq -U%U@%M -P%p lprm command = /usr/bin/lprm -U%U@%M -P%p %j lppause command = /usr/sbin/lpc -U%U@%M hold %p %j lpresume command = /usr/sbin/lpc -U%U@%M release %p %j queuepause command = /usr/sbin/lpc -U%U@%M -P%p stop queueresume command = /usr/sbin/lpc -U%U@%M -P%p start Sorry about the size of this :-) Cheers, GrantB
I fixed a few memory leaks related to the print handle cache. Don't remember what vcersion though. Please reopn this bug if the leak still exists in the latest 3.0.x release.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.