Hello,
We have been running samba v2 for quite some time without any problems.
But after the upgrade to samba-3.0.5 some anomalies have come out. I've
compiled it with LDAP authentication support; the LDAP server is
installed on the same machine and the communication is done via sockets.
After working fine for some time, and as usual creating multiple threads
from the smbd proccess, it suddenly goes into an infinite loop;
Running strace on that thread shows:
open("/etc/passwd", O_RDONLY) = 28
fcntl64(28, F_GETFD) = 0
fcntl64(28, F_SETFD, FD_CLOEXEC) = 0
fstat64(28, {st_mode=S_IFREG|0644, st_size=852, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x4033d000
read(28, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 852
read(28, "", 4096) = 0
close(28) = 0
munmap(0x4033d000, 4096) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [PIPE], NULL, 8) = 0
getpid() = 19340
geteuid32() = 65534
getpid() = 19340
geteuid32() = 65534
time(NULL) = 1093339331
write(26, "0\201\305\2\3%\302\233c\201\275\4\25ou=users,dc=21k,dc"...,
200) = 200
select(1024, [26], [], NULL, NULL) = 1 (in [26])
read(26, "0\16\2\3%\302\233e", 8) = 8
read(26, "\7\n\1\0\4\0\4\0", 8) = 8
time(NULL) = 1093339331
time([1093339331]) = 1093339331
rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_IGN}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [PIPE], NULL, 8) = 0
open("/etc/passwd", O_RDONLY) = 28
fcntl64(28, F_GETFD) = 0
fcntl64(28, F_SETFD, FD_CLOEXEC) = 0
fstat64(28, {st_mode=S_IFREG|0644, st_size=852, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x4033d000
read(28, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 852
read(28, "", 4096) = 0
close(28) = 0
munmap(0x4033d000, 4096) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
.....
While normally working smbd threads are owen by the user who is logged
into the domain, the looping ones are always run by the nobody-user:
nobody 19339 4.3 1.2 7012 3976 ? S 02:26 29:07
/usr/local/samba/sbin/smbd -D
nobody 19341 4.2 1.2 7012 3976 ? S 02:26 28:30
/usr/local/samba/sbin/smbd -D
nobody 19342 4.0 1.2 7012 3980 ? S 02:26 26:56
/usr/local/samba/sbin/smbd -D
nobody 19343 3.9 1.2 7012 3976 ? S 02:26 26:15
/usr/local/samba/sbin/smbd -D
I've tested the exactly the same configuration on the other machine and
it works fine, no looping.
Any ideas, how to solve this problem or what to look for?
--
Best wishes,
The Ranger
Whats your log level set at? I've had it set at 10 before and its pegged out the processor. Maybe thats all it is. The Ranger wrote:> Hello, > > We have been running samba v2 for quite some time without any problems. > But after the upgrade to samba-3.0.5 some anomalies have come out. I've > compiled it with LDAP authentication support; the LDAP server is > installed on the same machine and the communication is done via sockets. > > After working fine for some time, and as usual creating multiple threads > from the smbd proccess, it suddenly goes into an infinite loop; > > Running strace on that thread shows: > > open("/etc/passwd", O_RDONLY) = 28 > fcntl64(28, F_GETFD) = 0 > fcntl64(28, F_SETFD, FD_CLOEXEC) = 0 > fstat64(28, {st_mode=S_IFREG|0644, st_size=852, ...}) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0x4033d000 > read(28, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 852 > read(28, "", 4096) = 0 > close(28) = 0 > munmap(0x4033d000, 4096) = 0 > rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [PIPE], NULL, 8) = 0 > getpid() = 19340 > geteuid32() = 65534 > getpid() = 19340 > geteuid32() = 65534 > time(NULL) = 1093339331 > write(26, "0\201\305\2\3%\302\233c\201\275\4\25ou=users,dc=21k,dc"..., > 200) = 200 > select(1024, [26], [], NULL, NULL) = 1 (in [26]) > read(26, "0\16\2\3%\302\233e", 8) = 8 > read(26, "\7\n\1\0\4\0\4\0", 8) = 8 > time(NULL) = 1093339331 > time([1093339331]) = 1093339331 > rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_IGN}, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [PIPE], NULL, 8) = 0 > open("/etc/passwd", O_RDONLY) = 28 > fcntl64(28, F_GETFD) = 0 > fcntl64(28, F_SETFD, FD_CLOEXEC) = 0 > fstat64(28, {st_mode=S_IFREG|0644, st_size=852, ...}) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0x4033d000 > read(28, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 852 > read(28, "", 4096) = 0 > close(28) = 0 > munmap(0x4033d000, 4096) = 0 > rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 > > ..... > > > While normally working smbd threads are owen by the user who is logged > into the domain, the looping ones are always run by the nobody-user: > > nobody 19339 4.3 1.2 7012 3976 ? S 02:26 29:07 > /usr/local/samba/sbin/smbd -D > nobody 19341 4.2 1.2 7012 3976 ? S 02:26 28:30 > /usr/local/samba/sbin/smbd -D > nobody 19342 4.0 1.2 7012 3980 ? S 02:26 26:56 > /usr/local/samba/sbin/smbd -D > nobody 19343 3.9 1.2 7012 3976 ? S 02:26 26:15 > /usr/local/samba/sbin/smbd -D > > > I've tested the exactly the same configuration on the other machine and > it works fine, no looping. > > > Any ideas, how to solve this problem or what to look for? > > > > -- > Best wishes, > The Ranger >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Ranger wrote: | Hello, | | We have been running samba v2 for quite some | time without any problems. But after the upgrade | to samba-3.0.5 some anomalies have come out. I've | compiled it with LDAP authentication support; the | LDAP server is installed on the same machine and | the communication is done via sockets. Looks for old account names in /etc/group lines (objectclass=posixGroup). There was a bug that would have caused the problem you describe. It was fixed in 3.0.6. cheers, jerry - --------------------------------------------------------------------- Alleviating the pain of Windows(tm) ------- http://www.samba.org GnuPG Key ----- http://www.plainjoe.org/gpg_public.asc "If we're adding to the noise, turn off this song"--Switchfoot (2003) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBK1Y2IR7qMdg1EfYRAjAYAJwJ7OzDUmN226YkmfXuKVw0M79pEQCaA3aE a4NnyzADbv1m36TmJZNDh90=8p8A -----END PGP SIGNATURE-----
Gerald (Jerry) Carter wrote:> Looks for old account names in /etc/group lines > (objectclass=posixGroup). There was a bug that would > have caused the problem you describe. It was fixed > in 3.0.6.Guess I have to try another upgrade then. Hope it fixes it. In this case it is strange that the other system with the exactly same configuration does not suffer under this anomaly. -- rgrds, Ranger