SUMMARY Re: Samba "Incurred fault #32" on ES40

From: Graham Allan (allan_at_physics.umn.edu)
Date: 05/03/05

  • Next message: Beck, Jeff: "Ultra scsi 2 disks" 
    Date: Tue, 03 May 2005 12:19:05 -0500
To: tru64-unix-managers@ornl.gov

    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@umn.edu - (612) 624-5040
School of Physics and Astronomy - University of Minnesota
-------------------------------------------------------------------------
  • Next message: Beck, Jeff: "Ultra scsi 2 disks"

    Relevant Pages