vsftpd fails to start on boot when using pasv_addr_resolve

Bug #563973 reported by up-whatever
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
vsftpd (Ubuntu)
Expired
Medium
Unassigned

Bug Description

Binary package hint: vsftpd

On Lucid (this problem probably also exists in Karmic) vsftpd 2.2.2-3ubuntu5 fails to start automatically on boot when pasv_addr_resolve is used.
The reason for this is that vsftpd tries to resolve the domain name given in this setting, but eth0 is not yet up at the time vsftpd is called by upstart.

The result in syslog:
[...]
Apr 15 10:36:30 desktop init: vsftpd main process (986) terminated with status 1
Apr 15 10:36:30 desktop init: vsftpd main process ended, respawning
Apr 15 10:36:30 desktop init: vsftpd main process (989) terminated with status 1
Apr 15 10:36:30 desktop init: vsftpd main process ended, respawning
Apr 15 10:36:30 desktop init: vsftpd main process (992) terminated with status 1
Apr 15 10:36:30 desktop init: vsftpd main process ended, respawning
Apr 15 10:36:30 desktop init: vsftpd main process (995) terminated with status 1
Apr 15 10:36:30 desktop init: vsftpd respawning too fast, stopped

Both; not using pasv_addr_resolve or waiting till eth0 is up fixes the problem.
I fixed this by adding IFACE=eth0 to the start conditions in /etc/init/vsftpd.conf, but this assumes eth0 is your default network interface.

This bug is probably related to #277114

Related branches

Scott Moser (smoser)
Changed in vsftpd (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package vsftpd - 2.2.2-3ubuntu6

---------------
vsftpd (2.2.2-3ubuntu6) lucid; urgency=low

  * debian/vsftpd.upstart: Update upstart job. (LP: #563973)
 -- Chuck Short <email address hidden> Thu, 15 Apr 2010 13:28:58 -0400

Changed in vsftpd (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Gerard van Dorst (gerard-tachyonspace) wrote :

Problem still exists

vsftpd: version 2.2.2

May 16 00:15:01 vps3532 init: vsftpd main process ended, respawning
May 16 00:15:01 vps3532 init: vsftpd main process (11238) terminated with status 1
May 16 00:15:01 vps3532 init: vsftpd main process ended, respawning
May 16 00:15:01 vps3532 init: vsftpd main process (11241) terminated with status 1
May 16 00:15:01 vps3532 init: vsftpd main process ended, respawning
May 16 00:15:01 vps3532 init: vsftpd main process (11244) terminated with status 1
May 16 00:15:01 vps3532 init: vsftpd main process ended, respawning
May 16 00:15:01 vps3532 init: vsftpd main process (11247) terminated with status 1
May 16 00:15:01 vps3532 init: vsftpd main process ended, respawning
May 16 00:15:01 vps3532 init: vsftpd main process (11250) terminated with status 1
May 16 00:15:01 vps3532 init: vsftpd respawning too fast, stopped

Changed in vsftpd (Ubuntu):
status: Fix Released → Incomplete
Revision history for this message
jbfoley (jbfoley) wrote :

Not a big deal for me, since I reboot the server rarely and have added this to /etc/rc.local, but FWIW, I have encountered this strange behavior as well. Using 10.04 Server and vsftpd. Can provide more detailed info if needed.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for vsftpd (Ubuntu) because there has been no activity for 60 days.]

Changed in vsftpd (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.