Hi I am having the exact same problem. Did anyone every solve it? It occurs on both of my samba servers, one of which is not being used. Jason ----- original message ----- Hi, Hopefully someone can help me with this because its driving me up the wall. I admin a Samba PDC which authenticates through an LDAP backend. Both the samba server and pam authenticate through the entries in the LDAP database. I recently upgraded to 3.0.4 to combat the M$ hotfix that destroyed password changing. Since then things have been squiffy. All runs fine (apart from a grouping problem that I shall describe later) until a rogue samba thread appears which is owned by "nobody". PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 2639 root 20 0 13844 3832 804 S 40.8 1.5 4317m 0 slapd 7889 nobody 15 0 1528 492 372 S 4.9 0.1 76:19 0 smbd This particular top output is probably a bad example because the nightly backups are running at the same time. However the exhaustion of slapd as shown above occurs at the same time as this "nobody" thread appears. When the backup is not running the smbd thread usually hits about 40% CPU as well leading to a very congested fileserver. At this point the network slows to a crawl, killing these processes stops the slapd cpu usage but seems then to corrupt peoples smb sessions which seems to suggest the process is actually associated with a user. In trying to track down this bug I've rearranged the entire ldap tree; we used to have an "ou=smb" tree for all samba classes and "ou=People" and "ou=Group" trees for all the posix classes. These have ow been rearranged so that ou=People,ou=Computers and ou=Group exist with both their posix and samba attributes in each respective tree. I would really, really appriciate any help that you people can give. I've had success tracking down samba problems in the past but this one has me.
Greg Folkert
2004-Jul-27 23:43 UTC
[Samba] Problems with "nobody" processes in Samba 3.0.4
Comments inline. On Tue, 2004-07-27 at 18:22, Jason wrote:> Hi > > I am having the exact same problem. Did anyone every solve it? It occurs on > both of my samba servers, one of which is not being used. > > Jason > > > ----- original message ----- > > Hi, > > Hopefully someone can help me with this because its driving me up the > wall. I admin a Samba PDC which authenticates through an LDAP backend. > Both the samba server and pam authenticate through the entries in the > LDAP database. > > I recently upgraded to 3.0.4 to combat the M$ hotfix that destroyed > password changing. Since then things have been squiffy. All runs fine > (apart from a grouping problem that I shall describe later) until a > rogue samba thread appears which is owned by "nobody". > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND > 2639 root 20 0 13844 3832 804 S 40.8 1.5 4317m 0 slapd > 7889 nobody 15 0 1528 492 372 S 4.9 0.1 76:19 0 smbd > > This particular top output is probably a bad example because the nightly > backups are running at the same time. However the exhaustion of slapd as > shown above occurs at the same time as this "nobody" thread appears. > When the backup is not running the smbd thread usually hits about 40% > CPU as well leading to a very congested fileserver. At this point the > network slows to a crawl, killing these processes stops the slapd cpu > usage but seems then to corrupt peoples smb sessions which seems to > suggest the process is actually associated with a user. > > In trying to track down this bug I've rearranged the entire ldap tree; > we used to have an "ou=smb" tree for all samba classes and "ou=People" > and "ou=Group" trees for all the posix classes. These have ow been > rearranged so that ou=People,ou=Computers and ou=Group exist with both > their posix and samba attributes in each respective tree. > > I would really, really appriciate any help that you people can give. > I've had success tracking down samba problems in the past but this one > has me.From what I have seen, this is caused from having some (l)user in a group that does not exist as a (l)user. Check your configs, and make sure they are right. It can be as minor as a mistype. (that was a problem on one of my installations... DOH!) -- greg, greg@gregfolkert.net The technology that is Stronger, better, faster: Linux -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.samba.org/archive/samba/attachments/20040727/30e04d4d/attachment.bin