Jeremy,
I think I've tracked down the problem (sort of). In a little test
environment, I have a server and two machines. The server is the file
server for the two machines and is running Samba 3.0.22. Client machine
A is a Linux box, client machine B is a Windows 2000 box. I open up a
Samba share from the Linux box like so:
smbclient -U user \\\\server\\user
This gives me an smb prompt (smb \>). When I execute a 'ps auxwww |
grep mbd', I see that one process reflected in the output.
Additionally, an smbstatus confirms this. Now, I type "exit" at that
prompt, and the share is closed. The ps command and smbstatus confirm
this. Wonderful, works just like it should...tears down the process
when it's done using it. Now for the Windows box... (take a deep
breath, but don't hold it, heh)...
I navigate through Windows Explorer to My Network Places and so on until
I get to the server. I open up a folder on the server. I execute the
'ps auxwww | grep mbd' and sure enough, there's the share. The
smbstatus command confirms this. Now, I close out that Windows Explorer
window I have open to the server. However, a 'ps auxwww | grep mbd'
shows that there is still a connection open to this folder.... an
smbstatus confirms.... After a few minutes, the user for that pid
changes to root, and the process just sits in there forever, sucking up
0.9% of memory. This happens with EVERY share Windows opens. I've
tried using the "deadtime" option to kill these...no dice, they still
hang around. In fact, the only thing that gets rid of them is a
'killall -9 smbd'. So, basically I'm stuck with restarting Samba every
time too many files/folders get opened on the server. Is this a bug in
3.0.22? Is there some option that is needed to kill Windows connections
to Samba servers? This is most troublesome!
This being said, I'm rather new to Linux administration, so I'm not
really sure how to strace this if this is in fact not a bug ( though
advice is humbly accepted ^_^ ). However, after seeing this on two
completely separate systems, I'm wondering if this is just the way I
have my smb.conf set up or if I should really be worried about this
being a bug? Here's a copy of my smb.conf, just in case (fyi, this
thing has a lot of stuff commented out so it isn't very pretty, and I'm
aware of the fact that "printer admin" is deprecated). Also, I have a
cleaner copy from my test environment if that would be more desirable.
Anyways, here it is:
# Global parameters
[global]
netbios name = PDC-COMPANY
workgroup = COMPANY
printer admin = @"Print Operators"
admin users= @"Domain Admins"
deadtime = 20
enable privileges = yes
server string = Samba Server %v
security = user
encrypt passwords = Yes
#min passwd length = 3
obey pam restrictions = No
ldap passwd sync = Yes
#unix password sync = Yes
#passwd program = /usr/sbin/smbldap-passwd -u %u
#passwd chat = "Changing password for*\nNew password*" %n\n
"*Retype new password*" %n\n"
#ldap passwd sync = Yes
log level = 3
syslog = 0
log file = /var/log/samba/log.%m
max log size = 100000
time server = Yes
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
mangling method = hash2
Dos charset = 850
Unix charset = ISO8859-1
logon script = logon.bat
logon drive = H:
logon home = \\%N\%u
logon path =
domain logons = Yes
os level = 67
preferred master = Yes
domain master = Yes
wins support = Yes
passdb backend = ldapsam:"ldap://127.0.0.1/ ldap://192.168.1.3/";
# passdb backend = ldapsam:"ldap://127.0.0.1/
ldap://slave.idealx.com";
# ldap filter = (&(objectclass=sambaSamAccount)(uid=%u))
ldap admin dn = cn=admin,dc=company,dc=com
ldap suffix = dc=company,dc=com
ldap group suffix = ou=Groups
ldap user suffix = ou=People
ldap machine suffix = ou=People
ldap idmap suffix = ou=People
#ldap ssl = start tls
add user script = /usr/sbin/smbldap-useradd -m "%u"
ldap delete dn = Yes
#delete user script = /usr/sbin/smbldap-userdel "%u"
add machine script = /usr/sbin/smbldap-useradd -w "%u"
add group script = /usr/sbin/smbldap-groupadd -p "%g"
#delete group script = /usr/sbin/smbldap-groupdel "%g"
add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /usr/sbin/smbldap-groupmod -x
"%u" "%g"
set primary group script = /usr/sbin/smbldap-usermod -g "%g" "%u"
# printers configuration
#printer admin = @"Print Operators"
load printers = Yes
#create mask = 0640
#directory mask = 0750
#nt acl support = No
printing = cups
printcap name = cups
#deadtime = 10
#guest account = nobody
#map to guest = Bad User
#dont descend = /proc,/dev,/etc,/lib,/lost+found,/initrd
#show add printer wizard = yes
; to maintain capital letters in shortcuts in any of the profile
folders:
preserve case = yes
short preserve case = yes
case sensitive = no
[homes]
comment = Home of %U, %u
read only = No
create mask = 0644
directory mask = 0775
browseable = No
oplocks = No
level 2 oplocks = No
[netlogon]
path = /home/netlogon/
read only = yes
browseable = Yes
write list = user1
valid users = @"Domain Users"
#[profiles]
# path = /home/profiles
# read only = no
# create mask = 0600
# directory mask = 0700
# browseable = No
# guest ok = Yes
# profile acls = yes
# csc policy = disable
# # next line is a great way to secure the profiles
# force user = %U
# # next line allows administrator to access all profiles
# valid users = %U @"Domain Admins"
[printers]
#comment = Network Printers
#printer admin = @"Print Operators"
#guest ok = yes
#printable = yes
#path = /home/spool/
#browseable = No
#read only = Yes
#printable = Yes
#print command = /usr/bin/lpr -P%p -r %s
#lpq command = /usr/bin/lpq -P%p
#lprm command = /usr/bin/lprm -P%p %j
comment = All Printers
path = /var/spool/cups
browseable = yes
public = yes
guest ok = yes
writable = no
printable = yes
printer admin = root, @"Print Operators"
[print$]
path = /home/printers
guest ok = Yes
browseable = Yes
read only = Yes
valid users = @"Domain Users"
write list = @"Print Operators"
#create mask = 0664
#directory mask = 0775
[public]
comment = Public Repository
path = /home/public
guest ok = Yes
read only = No
directory mask = 0775
create mask = 0664
oplocks = No
level 2 oplocks = No
[downloads]
comment = Helpful Downloads
path = /home/downloads
guest ok = Yes
read only = No
directory mask = 0775
create mask = 0664
write list = user1
valid users = @"Domain Users"
Jeremy Allison wrote:
On Mon, Jun 12, 2006 at 03:58:28PM -0400, Ryan Steele wrote:
I've tried *everything* short of strace-ing, and I'm running out of
options and time to get this working. If anyone has had similar
Then I'd try strace, and also attach with gdb and see where
the spinning smbd's are spending their time.
Jeremy.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
