Bug 109933 - vsftpd listener hangs
vsftpd listener hangs
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: vsftpd (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-12 23:21 EST by Chris Adams
Modified: 2014-03-16 22:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-25 16:40:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Chris Adams 2003-11-12 23:21:55 EST
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.
Comment 1 Bill Nottingham 2003-11-12 23:39:06 EST
If you attach with gdb and do a backtrace, where is it?
Comment 2 Chris Adams 2003-11-13 09:37:18 EST
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?
Comment 3 Chris Adams 2003-11-13 09:50:21 EST
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?)
Comment 4 Bill Nottingham 2003-11-13 11:30:54 EST
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.)
Comment 5 Chris Adams 2003-11-16 16:13:13 EST
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.
Comment 6 Chris Adams 2003-11-16 18:46:06 EST
No-go; the FC1 package hung again, and again I got a useless trace. 
I've switched back to the non-PIE vsftpd.
Comment 7 Chris Adams 2003-11-17 14:43:41 EST
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.
Comment 8 Olivier Baudron 2004-03-11 03:51:58 EST
I have exactly the same problem (hang + zombies) on a bi-pro Dell
PE1750 running FC1.
Comment 9 Olivier Baudron 2004-03-25 09:03:03 EST
For me, the problem is fixed. See patch at bug 109933.
Chris, would you give it a try?
Comment 10 Olivier Baudron 2004-03-25 09:04:07 EST
Oops, I meant patch at bug 119136.
Comment 11 Chris Adams 2004-04-07 20:04:25 EDT
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.
Comment 12 Olivier Baudron 2004-04-29 03:20:04 EDT
Fixed in 1.2.1-4 and in upstream release 1.2.2
Comment 13 Chris Adams 2004-05-25 16:07:46 EDT
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?
Comment 14 Bill Nottingham 2004-05-25 16:40:58 EDT
Will be fixed with a FC1 update RSN. Should go into testing today,
final by Friday if there are no problems.

Note You need to log in before you can comment on or make changes to this bug.