sorry - I should have sent this to the list instead of just you - did
this help?
Just out of interest and because this helped me once - try apt-getting
nscd and start it and see if it works then.
Secondly, do you know your LDAP is working? Is it using nsswitch and
PAM?
Michael Moritz
Rémi Letot wrote:
Eduard Ballester <[EMAIL PROTECTED]> writes:
hi
swoog (192.168.50.11[192.168.50.11]) - ProFTPD terminating (signal 11)
Does it ring a bell ?
There is no sufficient information, perhaps you must up the debug
level (try -d 9). If you can't see the error, try to run it without
mod_ldap configuration (using your system users).
upping the debug level doesn't provide anything more (actually it
seems 5 is the maximum debug level)
working without ldap works fine
working with ldap+tls doesn't work because the ldap server can't speak
tls, but in that case proftpd doesn't die. It simply answers 'no such
user'.
If nothing works you can use a strace command (system call tracer) to
obtain more data. The most simple use is strace -p
As proftpd spawns a new daemon for each incomming connection, I did an
strace -fn $proftpdpid, and here is what comes out when I try to
connect : (snipped the former lines as it's quite long)
-<
[pid 23172] read(5, "127.0.0.1\tswoog\tlocalhost\n192.16"..., 4096) =
312
[pid 23172] read(5, "", 4096) = 0
[pid 23172] close(5)= 0
[pid 23172] munmap(0x40015000, 4096)= 0
[pid 23172] socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5
[pid 23172] connect(5, {sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("192.168.60.5")}}, 28) = 0
[pid 23172] send(5,
"\226\271\1\0\0\1\0\0\0\0\0\0\tlocalhost\0\0\34\0\1", 27, 0) = 27
[pid 23172] gettimeofday({1057942581, 978654}, NULL) = 0
[pid 23172] poll([{fd=5, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
[pid 23172] recvfrom(5,
"\226\271\205\200\0\1\0\0\0\1\0\0\tlocalhost\0\0\34\0\1"..., 1024, 0,
{sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("192.168.60.5")}}, [16]) = 68
[pid 23172] close(5)= 0
[pid 23172] socket(PF_UNIX, SOCK_STREAM, 0) = 5
[pid 23172] connect(5, {sin_family=AF_UNIX,
path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or
directory)
[pid 23172] close(5)= 0
[pid 23172] open("/etc/hosts", O_RDONLY) = 5
[pid 23172] fcntl64(5, F_GETFD) = 0
[pid 23172] fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
[pid 23172] fstat64(5, {st_mode=S_IFREG|0644, st_size=312, ...}) = 0
[pid 23172] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000
[pid 23172] read(5, "127.0.0.1\tswoog\tlocalhost\n192.16"..., 4096) =
312
[pid 23172] read(5, "", 4096) = 0
[pid 23172] close(5)= 0
[pid 23172] munmap(0x40015000, 4096)= 0
[pid 23172] socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
[pid 23172] fcntl64(5, F_GETFL) = 0x2 (flags O_RDWR)
[pid 23172] fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid 23172] connect(5, {sin_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("127.0.0.1")}}, 16) = -1 EINPROGRESS (Operation now
in progress)
[pid 23172] select(1024, NULL, [5], NULL, NULL) = 1 (out [5])
[pid 23172] getpeername(5, {sin_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("127.0.0.1")}}, [16]) = 0
[pid 23172] fcntl64(5, F_GETFL) = 0x802 (flags
O_RDWR|O_NONBLOCK)
[pid 23172] fcntl64(5, F_SETFL, O_RDWR) = 0
[pid 23172] getpeername(5, {sin_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("127.0.0.1")}}, [16]) = 0
[pid 23172] brk(0x80af000) = 0x80af000
[pid 23172] uname({sys="Linux", node="swoog", ...}) = 0
[pid 23172] time(NULL) = 1057942581
[pid 23172] write(5, "0\24\2\1\1`\17\2\1\2\4\10o=ispman\200\0", 22) =
22
[pid 23172] select(1024, [5], [], NULL, NULL) = 1 (in [5])
[pid 23172] read(5, "0\f\2\1\1a\7\n\1\0\4\0\4\0", 16384) = 14
[pid 23172] time(NULL) = 1057942581
[pid 23172] --- SIGSEGV (Segmentation fault) ---
[pid 23172] rt_sigaction(SIGSEGV, {SIG_DFL}, {0x804f4ac, [SEGV],
SA_RESTART|0x400}, 8) = 0
[pid 23172] write(2, "swoog (192.168.50.11[192.168.50."..., 71) = 71
[pid 23172] _exit(1)= ?
-<
And then the parrent process spawns some more lines before it stays
still waiting for a new connection.
The sig11 is clearly there, but I'm not a developper, so can someone
interpret this? Or is it still too scarse in informations? If more
info is needed, how can I provide it ?
I have tried to recompile debian's package with the latest release of
mod_ldap, but it displays the same behaviour.
Thanks for your help,
