Red Hat Bugzilla – Bug 109933
vsftpd listener hangs
Last modified: 2014-03-16 22:40:21 EDT
I installed FC1 on my mirror server this afternoon, and (in the
process) switched from proftpd to vsftpd. I made a few config changes:
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
welcome to change it and/or distribute copies of it under certain
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
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".
Reading symbols from /usr/lib/libwrap.so.0...
Reading symbols from
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.
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.
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.
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.
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.
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.
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)
#0 0x00822c32 in ?? () at rtld.c:276 from /lib/ld-linux.so.2
#1 0x00923046 in ?? ()
#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
Previous frame identical to this frame (corrupt stack?)
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
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.