I believe I have uncovered a problem that has been plaguing many people
on the user lists, variously reported as browsing slowdowns, printing
slowdowns/stalls, etc.
The issue has to do with WINS name queries when smbd and nmbd as a WINS
server are on the same machine. I believe this problem exists in Samba
2.2.2, 2.2.4, 2.2.5 and 2.2.7a (yes - I have run all of those). So with
a configuration like:
** (irrelevant settings omitted) **
[global]
security = user
domain master = yes
wins support = yes
interfaces = 192.168.1.0/24
bind interfaces only = true
(default name resolve order = lmhosts host wins bcast)
With this configuration, any name query which reaches
libsmb\resolve_wins() will result in:
wins_srv_died(): Could not mark WINS server 127.0.0.1 down.
This message is emitted after repeated unsuccessful query attempts to
127.0.0.1 (which are timeouts) - resulting in > 6 second delay for name
resolution.
On the outside, the problem would appear to be somewhat intermittent
because the subsequent broadcast will update the name cache, and
additional queries for the same name will resolve much faster (by not
reaching resolve_wins()).
As a temporary solution, adding 127.0.0.0/8 to the "interfaces =" fixes
the problem. However, it's not clear to me why this would work (I don't
think it should) - why would NMBD need to open a session to SMBD to do
name resolution? Also, I'm not sure if "bind interfaces only = false"
would acquire the 127.0.0.1 interface anyway and/or cause some other
sequence to fix this problem (I can't test that hypothesis since I only
have exposed production servers to work with).
One could argue this is a configuration problem. However, I think that
would be the wrong way to think about this. First, the documentation
(including most recent smb.conf man page -- which is really much
improved -- kudos), gives the impression that 1) the "bind interfaces
only = false" setting won't try to acquire 127.0.0.1 anyway, and 2)
"interfaces = " is only for SMBD sessions. Second, if a setting is
required for proper operation, the code should just enforce the
requirement. Third, if this really is responsible for a lot of
complaints, head-scratching, unresolved issues, would we rather continue
to have to deal with it or just fix it?
I initially followed this problem in via the RFFPCNEX spool_ss handler
(which needs to resolve the client name), but I believe there are many
other circumstances in which this would happen. E.g.,
nmblookup -U 127.0.0.1 -R "WHATEVER#20"
gives the same results.
Other configurations may exhibit the same problem. E.g., I don't think
"domain master = yes" is required for this problem to be present (it
does in my case since I was tracking it through the print server).
I apologize in advance if, in my ignorance of the architecture of Samba,
I can't shed more light on the problem or this is a more isolated
circumstance than I think and not cause for much concern.
I also want to take this opportunity to say thank you to the core Samba
team and other significant contributors to Samba. Thanks for a great
product, hard work and dedication.
Sincerely,
Peter Hurley
[EMAIL PROTECTED]
PS - To Jerry, this is a follow-up to an e-mail I sent directly to you
RE: RFFPCNEX stall feedback.
