We found the cure:
Remove "ldap" from the netgroups line of /etc/nsswitch.conf
Discovered from truss as smbd was accessing the netscape ldap
certificate files /etc/cert7.db, despite being linked against openldap.
It's possible that samba had not been restarted since ldap was added to
nsswitch.conf a month or so ago. One certainly wouldn't expect a config
change like this to break a previously working application, but...
We did "sort of" get ldap netgroups working a while back, but it was
always on the todo-list to either email the list about or open a
support call, as it's very inconsistent, not to mention almost
undocumented.
At present, we have several systems which are successfully using ldap
for netgroups. They're all running 5.1B PK3. Those running PK4
generally don't work, although the samba server did have PK4 and was
using ldap netgroups successfully prior to today. I've re-enabled NIS
purely for netgroups support, for now.
On PK3 machines, "lsof" shows that mountd makes a direct connection to
the ldap server. On PK4 machines, there is no such connection, *but* a
small C program written to enumerate the netgroups contents does work!
Goodness knows what is going on. If ldap netgroups (presumably
/usr/shlib/libnss_ldap.so) doesn't operate through ldapcd and
ldapcd.conf, then I don't even see where it gets its configuration from
(how does it know where the ldap server is?) - yet if it does operate
through ldapcd, then why does the PK3 mountd itself connect to the ldap
server?
Graham
On Tue, May 03, 2005 at 10:39:39AM -0500, Graham Allan wrote:
> We've had Samba 3.0.x running for about a year now on our ES40, Tru64
> 5.1B PK4. Suddenly yesterday it went badly wrong, for no apparent
> reason - all smbd processes become cpu-bound, though they function
> (slowly). Load average on the server heads up towards 200 or so unless
> we kill samba. We tried a bunch of things ranging from tweaking the
> samba config (which has worked for a long time unchanged), updating
> samba from 3.0.11 to 3.0.14a, to restarting the system. No change.
>
> Attaching to a cpu-bound smbd with truss shows rapid repeated
> occurances of:
>
> Incurred fault #32, FLTBOUNDS %pc = 0x000003FF801D40BC
> addr = 0x000000011FFF8C40
>
> the memory addresses stay contant across processes and samba restarts.
>
> This is perhaps more samba related than Tru64, but while we continue to
> look for a cause, I thought I'd throw this out to the list, to see if
> anyone has any ideas about interpreting it...
>
> Graham
> --
> -------------------------------------------------------------------------
> Graham Allan
> School of Physics and Astronomy - University of Minnesota
> -------------------------------------------------------------------------
--
-------------------------------------------------------------------------
Graham Allan - I.T. Manager - gta_at_umn.edu - (612) 624-5040
School of Physics and Astronomy - University of Minnesota
-------------------------------------------------------------------------
Received on Tue May 03 2005 - 17:43:26 NZST