Ubuntu natty Proftpd start fails at boot time when using MasqueradeAddress and Network-manager

Bug #868885 reported by Christophe Van Reusel
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
proftpd-dfsg (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Since latest kernel upgrade off ubuntu natty 11.04. proftpd start at boot failed with message : - Fatal: MasqueradeAddress: unable to resolve "xxxxxxx.xxx.cx" on line 177 of '/etc/proftpd/proftpd.conf'. I'm using a relatively avanced proftpd config. With first just standalone base server on standard port for local network only and a virtual with tls (ftps) user apart who is jailed to certain maps and limited in possible ftpd commands. Accessible trough internet. Masquerading is necessary to have the passive ports opened to corect ip by the client.
I use network-manager to configure the interface. (it's easy with the applet to see your network status) .
When configure the proftpd without MasqueradeAddress it does start fine.
This all occur on my latest pc with intel core duo E8600 2 X 3,33 Ghz, and raptor hd's.
On my older pc amd64 athlon x2 dual core standard hd's with same ubuntu natty same configuration no problem. proftpd start always at boot time.
I figured out that with a fast pc proftpd starts whiles the network is not fully up when working trough network manager. Which causes a start failure as it cannot resolve the MasqueradeAddress yet.
I tried to give it the highest possible start number into runlevel 2,3,4,5 . But still the same problem. When I configured my network adapter trough /network/interfaces no problem proftpd started well.(But I like to have the network status with the nm-applet) With inetd also no problem but I do not want a pid for each session.

I do now found out a solution (that's why a fill a bug repport it would be nice to include this into further ubuntu versions)
I first removed the standard upstart with update-rc.d -f proftpd remove.
Created an upstart conf into /etc/init

named proftpd.conf

# Proftpd
#Use this instead of standard(old) rc.d When using network manager
#and dns masquer address Otherwise proftp start may fail due to no dns lookup avbl yet
#during boottime. With this proftpd will only start when network device is up
#

description "proftpd"

start on (local-filesystems and net-device-up IFACE!=lo)

stop on stopping dbus

exec /etc/init.d/proftpd start

Now proftpd does start fine again at boot time. And is also avbl without local login.

Revision history for this message
Christophe Van Reusel (christophevr) wrote :

I changed the proftpf.conf into /etc/init A bit more logical now

I do not now if one of the developpers just saw this message Yet.

Here startup proftp conf which work's very good on ubuntu natty while using network manager on fast pc

# Proftpd
#Use this instead of standard(old) rc.d When using network manager
#and dns masquer address Otherwise proftp start may fail due to no dns lookup avbl yet
#during boottime. With this proftpd will only start when network device is up
#

description "proftpd"

start on (local-filesystems and net-device-up IFACE!=lo)
stop on runlevel [016]

expect fork
respawn

pre-start script
 mkdir -p /var/run/proftpd

end script

script

exec proftpd -c /etc/proftpd/proftpd.conf

end script

I put the prestart to make the /var/run/proftpd map. Currently on natty it is not needed as the proftpd files are into
/var/run map . But I guess that this is just a small thing which was done wrong at compile time from the proftpd package in ubuntu self because the basic included proftpd.conf file mentions /var/run/proftpd for control purposes. (which i changed by me) .

I also used expect fork so that we see the process pid from proftpd with initctl list command.
exctract initctl list

proftpd start/running, process 1949

tags: added: ubuntu upstart
summary: - Ubuntu natty Proftpd start fails at boot time
+ Ubuntu natty Proftpd start fails at boot time when using
+ MasqueradeAddressMasqueradeAddress
summary: Ubuntu natty Proftpd start fails at boot time when using
- MasqueradeAddressMasqueradeAddress
+ MasqueradeAddress and Network-manager
Revision history for this message
Xebec (xebec-yandex) wrote :

Both of your solutions are wrong. When proftpd starts in daemon mode, upstart fails for some reason to get PID of the process. I tried both "expect fork" and "expect daemon" - to no help. Yes, proftpd starts just fine, but you'll fail to stop it. I tried proftpd in no-daemon mode "-n -q" - fails to start before I boot. Still looking for a good solution.

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

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in proftpd (Ubuntu):
status: New → Confirmed
Revision history for this message
Christophe Van Reusel (christophevr) wrote :

@Xebec

Woowh That's a long time after intial. message. But it does work out well.

Note do not start in deamon mode, just use upstart.

Before using it with upstart first remove the start link's with update rc.d .

If you wan't to stop proftpd just do it with sudo killall -9 proftpd.

The fact that proftpd does not start in deamon mode when masquerading is used,

-Does only happen when networkmanager is used and a fast pc is used. It's actually a runtime bug.

Maybe modifying the start up deamon into /etc/init.d self could be a solution, I actually never thaught about playing around with that. As it does work good when using upstart. Note networkmanager does start up deamonized as well, ass long You are not using wireless connections, No problem occurs. (I configured well a fix ip trough network manager and I use cable network)

When using wireless connection, You always will need to start proftpd manually AFTER You connection is made (with network manager this only happens after user login) When using masquerade.

Revision history for this message
Xebec (xebec-yandex) wrote :

Christophe, of course I removed all links from rc* before I wrote my /etc/init/xebec-proftpd.conf. I know how to stop the process. The problem is not in starting it (as it starts just fine with either of your scripts) and stopping it at reboot (as it is killed naturally) or by kill. The problem is in writing correct upstart init script for it, so that upstart was aware of its PID, could monitor its status and stop it when I call "stop xebec-proftpd". I tried all possible permutations of using/not using start-stop-daemon, starting proftpd in daemon/nodaemon modes, specifying "expect fork", "expect daemon" and not specifying. I even tried using nondocumented pid directive in upstart script - all to no luck. In all cases either proftpd refuses to start on my boot events but starts/stops manually, or upstart starts it successfully but loses its PID.

I know your scripts starts proftpd for you just fine, but go ahead and check its status or try to stop it correctly - you will fail.

Revision history for this message
Xebec (xebec-yandex) wrote :

BTW. I have this problem in Precise - not Natty. Wrote here since it was never marked as fixed.

Revision history for this message
Christophe Van Reusel (christophevr) wrote :

I did not used it with precise. Main pc still running natty.

And my other pc with 12.04 does not needs masquerading, then it's working fine without upstart

Revision history for this message
Xebec (xebec-yandex) wrote :

Turned out while testing some of the combinations, I was affected by a shamefully long time unresolved upstart bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582745 . Here is correct (in my opinion) version of my xebec-proftpd.conf:
# When to start the service
start on (local-filesystems and net-device-up IFACE!=lo)

# When to stop the service
stop on runlevel [016]

# Start the process
script
 exec /usr/sbin/proftpd -n -c /etc/proftpd/proftpd.conf >/dev/null 2>&1
end script

Revision history for this message
Amr Ibrahim (amribrahim1987) wrote :

In the future, please use 'ubuntu-bug package-name' to report Ubuntu bugs.
https://help.ubuntu.com/community/ReportingBugs

You have reported a bug in a non-existent package in Ubuntu archives since 2007. No developer will see this bug report because simply the package does not exist any more.

affects: proftpd (Ubuntu) → proftpd-dfsg (Ubuntu)
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.