I installed FC1 on my mirror server this afternoon, and (in the process) switched from proftpd to vsftpd. I made a few config changes: tcp_wrappers=NO setproctitle_enable=YES max_clients=100 max_per_ip=3 ftpd_banner=HiWAAY Public FTP Mirror and started it up. Every time I leave it running for a while (about 30 minutes), the LISTENER process hangs. New connections hang and closed connections leave zombie processes. I attached to the listener process with strace and got: futex(0x7fe300, FUTEX_WAIT, 2, NULL <unfinished ...> This is a quad PPro 200 running the SMP kernel.
If you attach with gdb and do a backtrace, where is it?
I installed the debuginfo packages for vsftpd, glibc.i686, glibc-common, tcp_wrappers, libcap, and pam (I think that covers everything), but I still just get lines of ?? from gdb. Is there some extra option I need to use to get useful information?
This time I did get something at the very bottom of the trace: #0 0x00bcfc32 in ?? () #1 0x00ccf3a6 in ?? () #2 0x00d1d300 in ?? () #3 0x00d1c998 in ?? () #4 0x00000011 in ?? () #5 0x00c5a19c in ?? () #6 0xbfe7abe8 in ?? () #7 0x00000010 in ?? () #8 0x00dccde4 in ?? () #9 0x08e63ed0 in ?? () #10 0xbfe7abe8 in ?? () #11 0xbfe7abb4 in ?? () #12 0x00dc4b76 in ?? () #13 0x08e63ed0 in ?? () #14 0x08e63ed0 in ?? () #15 0x00000004 in ?? () #16 0x00dccde4 in ?? () #17 0x00dccde4 in ?? () #18 0x08e63eb8 in ?? () #19 0xbfe7abd4 in ?? () #20 0x00dc3bcc in ?? () #21 0x08e63ed0 in ?? () #22 0xbfe7abe8 in ?? () #23 0x00000001 in ?? () #24 0x00dccde4 in ?? () #25 0xbfe7abe8 in ?? () #26 0x00d1d300 in ?? () #27 0xbfe7abf4 in ?? () #28 0x00dc38b9 in ?? () #29 0x08e63008 in ?? () #30 0xbfe7abe8 in ?? () #31 0x00000010 in ?? () #32 0x00004dca in vsf_cmdio_write_str (p_sess=0xfffffffc, status=-4, p_str=0xfffffffc) at ftpcmdio.c:105 Previous frame inner to this frame (corrupt stack?)
Does it behave better if you rebuild it removing the use of -fPIE in CFLAGS and -pie in LINK? (At least then you'll get something that you can get a backtrace out of.)
I got the hang after rebuilding without PIE, but prelink had run (so I couldn't get anything with gdb). I also installed the available updates (including the updates in testing), which included a glibc update. Since then, I let the non-PIE vsftpd run for a day or so with no problem at all. I've switched back to the FC1 vsftpd package to see if there is still a problem, but at the moment, I'm thinking it may have been a glibc problem solved in the update.
No-go; the FC1 package hung again, and again I got a useless trace. I've switched back to the non-PIE vsftpd.
The non-PIE version hung too. I got: GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu". (gdb) attach 23240 Attaching to process 23240 Reading symbols from /usr/sbin/vsftpd... Reading symbols from /usr/lib/debug//usr/sbin/vsftpd.debug...done. Using host libthread_db library "/lib/tls/libthread_db.so.1". done. Reading symbols from /usr/lib/libwrap.so.0... Reading symbols from /usr/lib/debug//usr/lib/libwrap.so.0.7.6.debug...done. done. Loaded symbols for /usr/lib/libwrap.so.0 Reading symbols from /lib/libnsl.so.1... Reading symbols from /usr/lib/debug//lib/libnsl-2.3.2.so.debug...done. done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libpam.so.0... Reading symbols from /usr/lib/debug//lib/libpam.so.0.77.debug...done. done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /lib/libcap.so.1... Reading symbols from /usr/lib/debug//lib/libcap.so.1.10.debug...done. done. Loaded symbols for /lib/libcap.so.1 Reading symbols from /lib/tls/libc.so.6... Reading symbols from /usr/lib/debug//lib/tls/libc-2.3.2.so.debug...done. done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/libdl.so.2... Reading symbols from /usr/lib/debug//lib/libdl-2.3.2.so.debug...done. done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux.so.2... Reading symbols from /usr/lib/debug//lib/ld-2.3.2.so.debug...done. done. Loaded symbols for /lib/ld-linux.so.2 0x00822c32 in ?? () at rtld.c:276 from /lib/ld-linux.so.2 276 _dl_start (void *arg) (gdb) where #0 0x00822c32 in ?? () at rtld.c:276 from /lib/ld-linux.so.2 #1 0x00923046 in ?? () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:64 from /lib/tls/libc.so.6 #2 0x00970140 in ?? () from /lib/tls/libc.so.6 #3 0x0096f7d8 in ?? () from /lib/tls/libc.so.6 #4 0x00000011 in ?? () #5 0x008adf0c in ?? () at stdlib.h:317 from /lib/tls/libc.so.6 #6 0x097b8190 in ?? () #7 0x00000004 in ?? () #8 0x097b8178 in ?? () #9 0xbff512cc in ?? () #10 0x097b6008 in ?? () #11 0xbff512b4 in ?? () #12 0x08053b11 in hash_free_entry (p_hash=0x97b8190, p_key=0x0) at hash.c:100 Previous frame identical to this frame (corrupt stack?) (gdb) quit Suggestions? For now, I'm going to switch back to proftpd I guess. I like vsftpd (much lighter weight), but it doesn't seem quite ready for prime time.
I have exactly the same problem (hang + zombies) on a bi-pro Dell PE1750 running FC1.
For me, the problem is fixed. See patch at bug 109933. Chris, would you give it a try?
Oops, I meant patch at bug 119136.
Sorry, I haven't been able to give it a try. I switched to using xinetd to run vsftpd and am using some of the features of xinetd to control connections (in ways that vsftpd doesn't do), so I'm not running vsftpd in listener mode.
Fixed in 1.2.1-4 and in upstream release 1.2.2
I rebuilt the FC2 vsftpd-1.2.1-5 RPM for FC1 and am using it fine now (xinetd wacked out on me so I switched back to vsftpd stand-alone). Is this going to be released as an FC1 update?
Will be fixed with a FC1 update RSN. Should go into testing today, final by Friday if there are no problems.