[FFE] tftpd-hpa doesn't start on boot

Bug #522509 reported by Alkis Georgopoulos
104
This bug affects 20 people
Affects Status Importance Assigned to Milestone
tftp-hpa (Ubuntu)
Fix Released
High
Chuck Short
Lucid
Fix Released
High
Chuck Short

Bug Description

Binary package hint: tftp-hpa

tftpd-hpa version: 5.0-11ubuntu1

tftpd-hpa doesn't start on boot for me:
syslog.1:Feb 16 08:26:43 alkis in.tftpd[1399]: cannot resolve local IPv4 bind address: 0.0.0.0, Name or service not known

But if I put a "sleep 30" on top of /etc/init.d/tftpd-hpa, then it does start.
Maybe the network isn't ready when the script runs?
Maybe it'd be better if tftpd-hpa was upstartified?

I didn't change any of my settings, they're the defaults:
# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure"

Revision history for this message
Thierry Carrez (ttx) wrote :

Maybe a duplicate of bug 461725...

Changed in tftp-hpa (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Revision history for this message
boukeas (boukeas) wrote :

I can confirm that tftp-hpa does not automatically start on boot.
My package version is the same.

Revision history for this message
Chuck Short (zulcss) wrote :

I have added upstart support to tftp-hpa but I think I need a FFE for it.

Regards
chuck

Changed in ltsp (Ubuntu):
status: New → Fix Committed
Thierry Carrez (ttx)
Changed in tftp-hpa (Ubuntu):
assignee: nobody → Chuck Short (zulcss)
milestone: none → ubuntu-10.04-beta-2
status: Confirmed → In Progress
Revision history for this message
apanagio (apanagio) wrote :

It also affects me.
I'm trying to convince fellow teachers to use ltsp at their school-labs and that bug is a major inconvenience for them.

please include the fix in the next beta

Revision history for this message
Chuck Short (zulcss) wrote :

I have converted the init job to an upstart job. Attached to this bug report. It should need a FFE.

Regards
chuck

summary: - tftpd-hpa doesn't start on boot
+ [FFE] tftpd-hpa doesn't start on boot
Revision history for this message
Chuck Short (zulcss) wrote :
Revision history for this message
Chuck Short (zulcss) wrote :
Revision history for this message
Steve Langasek (vorlon) wrote :

The start condition in this upstart job is wrong. It should be

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

The job should also have a stop condition so that the process isn't left running at shutdown:

  stop on runlevel [!2345]

+env DAEMON="/usr/sbin/in.tftpd"

This is not idiomatic. Please list the daemon name directly in the start script, instead of defining a variable that's only used once and should never be overridden.

diff -u tftp-hpa-5.0/debian/rules tftp-hpa-5.0/debian/rules
--- tftp-hpa-5.0/debian/rules
+++ tftp-hpa-5.0/debian/rules
@@ -24 +24 @@
- dh_installinit -a -- start 20 2 3 4 5 . stop 20 1 .
+ dh_installinit -u -- start 20 2 3 4 5 . stop 20 1 .

Has this package been build- and install-tested? By dropping the '-a', that looks to me like you're failing to specify any package at all for dh_installinit to act on. I don't know if that works - AFAICT the behavior is undefined.

Please make the mentioned revisions to the upstart job and send us an updated diff, with confirmation that the package builds and the job starts correctly in testing.

Changed in tftp-hpa (Ubuntu Lucid):
status: In Progress → Incomplete
Revision history for this message
Chuck Short (zulcss) wrote :

chuck@kenny:~/work/server/bugs/lucid/tftp-hpa/build$ sudo dpkg -i *.deb
(Reading database ... 278404 files and directories currently installed.)
Preparing to replace tftpd-hpa 5.0-11ubuntu2 (using tftpd-hpa_5.0-11ubuntu2_amd64.deb) ...
tftpd-hpa stop/waiting
Unpacking replacement tftpd-hpa ...
Selecting previously deselected package tftp-hpa.
Unpacking tftp-hpa (from tftp-hpa_5.0-11ubuntu2_amd64.deb) ...
Setting up tftpd-hpa (5.0-11ubuntu2) ...
tftpd user (tftp) already exists, doing nothing.

tftpd-hpa directory (/var/lib/tftpboot) already exists, doing nothing.
tftpd-hpa start/running, process 15904

Setting up tftp-hpa (5.0-11ubuntu2) ...
Processing triggers for man-db ...
chuck@kenny:~/work/server/bugs/lucid/tftp-hpa/build$ ps auxw | grep tftp
root 15904 0.0 0.0 14716 304 ? Ss 09:41 0:00 /usr/sbin/in.tftpd --listen --user tftp --address 0.0.0.0:69 --secure -s /var/lib/tftpboot
chuck 15962 0.0 0.0 7348 928 pts/10 S+ 09:41 0:00 grep --color=auto tftp

Revision history for this message
Chuck Short (zulcss) wrote :

This is the package installation:

chuck@kenny:~/work/server/bugs/lucid/tftp-hpa/build$ sudo dpkg -i *.deb
(Reading database ... 278404 files and directories currently installed.)
Preparing to replace tftpd-hpa 5.0-11ubuntu2 (using tftpd-hpa_5.0-11ubuntu2_amd64.deb) ...
tftpd-hpa stop/waiting
Unpacking replacement tftpd-hpa ...
Selecting previously deselected package tftp-hpa.
Unpacking tftp-hpa (from tftp-hpa_5.0-11ubuntu2_amd64.deb) ...
Setting up tftpd-hpa (5.0-11ubuntu2) ...
tftpd user (tftp) already exists, doing nothing.

tftpd-hpa directory (/var/lib/tftpboot) already exists, doing nothing.
tftpd-hpa start/running, process 15904

Setting up tftp-hpa (5.0-11ubuntu2) ...
Processing triggers for man-db ...
chuck@kenny:~/work/server/bugs/lucid/tftp-hpa/build$ ps auxw | grep tftp
root 15904 0.0 0.0 14716 304 ? Ss 09:41 0:00 /usr/sbin/in.tftpd --listen --user tftp --address 0.0.0.0:69 --secure -s /var/lib/tftpboot
chuck 15962 0.0 0.0 7348 928 pts/10 S+ 09:41 0:00 grep --color=auto tftp

Revision history for this message
Chuck Short (zulcss) wrote :
Revision history for this message
Chuck Short (zulcss) wrote :
Revision history for this message
Steve Langasek (vorlon) wrote :

Hi Chuck,

The updated debdiff still shows this:

  start on (local-filesystem and net-device-up IFACE=eth0)

please correct this to 'start on (filesystem and net-device-up IFACE!=lo)', as requested.

Thanks!

Revision history for this message
Chuck Short (zulcss) wrote :

As requested.

Revision history for this message
Steve Langasek (vorlon) wrote :

Thanks, that looks better.

However, I just noticed that '--upstart-only' is the wrong thing to be passing to dh_installinit here. You should only use --upstart-only for upstart jobs that are *not* replacing an existing init script. In this case, there's an existing init script of the same name, so you need to omit --upstart-only in order to pull in the code that cleans up the old init script for us automatically.

Other than that, FFe granted.

Changed in tftp-hpa (Ubuntu Lucid):
status: Incomplete → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package tftp-hpa - 5.0-11ubuntu2

---------------
tftp-hpa (5.0-11ubuntu2) lucid; urgency=low

  * debian/rules, debian/tftpd-hpa.upstart: Convert to upstart.
    (LP: #522509)
  * debian/tftpd-hpa.postinst: Add "-s" to /etc/default/tftpd-hpa.
    (LP: #531123)
 -- Chuck Short <email address hidden> Thu, 11 Mar 2010 12:40:07 -0500

Changed in tftp-hpa (Ubuntu Lucid):
status: Confirmed → Fix Released
StefanPotyra (sistpoty)
Changed in ltsp (Ubuntu Lucid):
status: Fix Committed → Fix Released
Revision history for this message
Luis Mondesi (lemsx1) wrote :

What happened here? there is no /etc/init/*.conf and/or init.d. And the /etc/default/tftp-hpa is missing...

$> apt-cache policy tftp-hpa
tftp-hpa:
  Installed: 5.0-11ubuntu2
  Candidate: 5.0-11ubuntu2
  Version table:
 *** 5.0-11ubuntu2 0
        500 http://archive.ubuntu.com/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

$> dpkg -L tftp-hpa
/.
/usr
/usr/bin
/usr/bin/tftp
/usr/share
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/tftp.1.gz
/usr/share/doc
/usr/share/doc/tftp-hpa
/usr/share/doc/tftp-hpa/README
/usr/share/doc/tftp-hpa/copyright
/usr/share/doc/tftp-hpa/changelog.gz
/usr/share/doc/tftp-hpa/changelog.Debian.gz

Revision history for this message
Luis Mondesi (lemsx1) wrote :

oh my, nevermind my previous comment... i just realized this is the client not the server.

sorry :-)

Revision history for this message
Darik Horn (dajhorn) wrote :

I got this bug with tftpd-hpa after an upgrade to Lucid. The solution for me was to add `sleep 10s` to the script stanza in the /etc/init/tftpd-hpa file.

Running `initctl restart tftpd-hpa` properly starts in.tftpd if it fails during system startup, so it follows that there could be a race.

Upstart doesn't log anything during the failure.

Revision history for this message
Darik Horn (dajhorn) wrote :

BTW, I'm running tftp-hpa 5.0-11ubuntu2, which is current for Lucid.

This bug seems to depend on the order of network interface plumbing, and probably expresses more frequently if one interface is configured by DHCP or is otherwise slow. My guess is that this bug does not express on computers with one ethernet interface.

Attached is a /etc/init/tftpd-hpa variant that reliably starts in.tftpd on my computer. It likely works because the default binding is 0.0.0.0 and the loopback interface is quickly available.

Consider reopening this ticket.

Revision history for this message
Scott Kitterman (kitterman) wrote : Re: [Bug 522509] Re: [FFE] tftpd-hpa doesn't start on boot

It's better to file a new bug.

Revision history for this message
jdobry (jdobry) wrote :

Same for me like #20 and I am not abble to find new bug

Revision history for this message
Diego Morales (dgmorales) wrote :

I have the same problem, using lucid latest package (5.0-11ubuntu2.1).

I have many interfaces configured in this machine, and nic bonding configured. Upstart seems to raise tftp when the first bond interface starts:

syslog.2.gz:Jun 13 14:17:02 <hostname> kernel: [ 3.923760] bnx2: eth1: using MSI
syslog.2.gz:Jun 13 14:17:02 <hostname> kernel: [ 3.924441] bonding: bond0: Warning: failed to get speed and duplex from eth1, assumed to be 100Mb/sec and Full.
syslog.2.gz:Jun 13 14:17:02 <hostname> kernel: [ 3.924451] bonding: bond0: enslaving eth1 as an active interface with an up link.
syslog.2.gz:Jun 13 14:17:02 <hostname> kernel: [ 3.925317] bonding: bond0: setting mode to 802.3ad (4).
syslog.2.gz:Jun 13 14:17:02 <hostname> kernel: [ 3.925348] bonding: bond0: Setting MII monitoring interval to 100.
syslog.2.gz:Jun 13 14:17:02 <hostname> kernel: [ 3.925395] bonding: bond0: Setting LACP rate to fast (1).
syslog.2.gz:Jun 13 14:17:02 <hostname> in.tftpd[842]: cannot resolve local IPv4 bind address: 0.0.0.0, Name or service not known
syslog.2.gz:Jun 13 14:17:02 <hostname> init: tftpd-hpa main process (842) terminated with status 66
syslog.2.gz:Jun 13 14:17:02 <hostname> init: tftpd-hpa main process ended, respawning
syslog.2.gz:Jun 13 14:17:02 <hostname> kernel: [ 4.129433] 802.1Q VLAN Support v1.8 Ben Greear <email address hidden>
syslog.2.gz:Jun 13 14:17:02 <hostname> kernel: [ 4.129436] All bugs added by David S. Miller <email address hidden>
syslog.2.gz:Jun 13 14:17:02 <hostname> kernel: [ 4.134009] bonding: bond0: link status definitely down for interface eth0, disabling it
syslog.2.gz:Jun 13 14:17:02 <hostname> kernel: [ 4.134012] bonding: Warning: bond0: link status changed for uninitialized port on eth0
syslog.2.gz:Jun 13 14:17:02 <hostname> kernel: [ 4.134017] bonding: bond0: now running without any active interface !

The "status tftpd-hpa" says the job is running, when it's not (should THAT happen?). stop/start raises the program just fine.

I tried to change the condition to "(filesystem and and started networking)", but that seems to start it even earlier. I've changed it to "(filesystem and net-device-up IFACE=bond0.80)" (bond0.80 is the last bond interface) and then it worked.

But the problem may actually be that bondX is !=lo, and it may come up before any of its slaves be available, resulting in the
"cannot resolve local IPv4 bind address: 0.0.0.0" error.

Should I open a new bug? If so, should it be on tftpd-hpa, or some other package?

Revision history for this message
AllenS (thehousecat) wrote :

Hi

I have the same problem with Precise (tftpd-hpa version 5.2-1ubuntu1). It seems exactly the same as #23 above.

status tftpd-hpa saying running when it definately isn't.

Diego, I don't really understand the 'change the condition' stuff you mention. Would you be able to explain in reasonably simple terms how to work round this problem. I rely on tftpd for routers to back up configs. Thanks!

dmesg | grep tftpf
[ 29.086131] init: tftpd-hpa main process (1181) terminated with status 66
[ 29.086151] init: tftpd-hpa main process ended, respawning

 grep tftpd /var/log/syslog
May 7 17:46:04 wombat in.tftpd[1181]: cannot resolve local IPv4 bind address: 0.0.0.0, Name or service not known
May 7 17:46:04 wombat kernel: [ 29.086131] init: tftpd-hpa main process (1181) terminated with status 66
May 7 17:46:04 wombat kernel: [ 29.086151] init: tftpd-hpa main process ended, respawning

Please let me know if you need more info.

Revision history for this message
Diego Morales (dgmorales) wrote :

Hello Allen,

As you may already know, the tftpd-hpa daemon is started on boot by the upstart system, as configured in the file /etc/init/tftpd-hpa.conf. This file contains a line beggining with "start on", which gives the *condition* in which upstart will start the daemon (by running the script that is defined in the same file).

The error message "cannot resolve local IPv4 bind address: 0.0.0.0, Name or service not known" tells us that there is no configured IP address when tftpd is started.

In my case, that happened because of the NIC bonding (multiple physical NICs configured as one logical NIC) configuration. The original "start on" condition (on lucid) is "start on (filesystem and net-device-up IFACE!=lo)". So when bondX gets up, that condition is satisfied, tftpd starts, but all the physical interfaces which are part of bondX are not ready yet, which gives the error, and makes tftpd exit. I changed the condition (in a non-generic, not even good way) so tftpd gets started later. It worked

Do you use nic bonding too?

I've just checked now that in Precise they changed the condition to "start on runlevel [2345]". I guess that should work even with bonding, don't remember if I tried that... Could it be another network configuration problem in your setup, maybe?

Revision history for this message
AllenS (thehousecat) wrote :

Thanks Diego

I've got start on runlevel [2345] in the /etc/init/tftpd-hpa.conf file (thanks, I didn't know about that).

As far a I can tell my interface is up long before tftpd starts:
dmesg | egrep 'eth0|tftpd'
[ 1.669351] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) c8:9c:dc:eb:f0:a5
[ 1.669354] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
[ 1.669389] e1000e 0000:00:19.0: eth0: MAC: 10, PHY: 11, PBA No: FFFFFF-0FF
[ 3.140380] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 4.878842] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[ 4.878845] e1000e 0000:00:19.0: eth0: 10/100 speed: disabling TSO
[ 4.879080] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 23.312049] eth0: no IPv6 routers present
[ 25.001150] init: tftpd-hpa main process (1253) terminated with status 66
[ 25.001171] init: tftpd-hpa main process ended, respawning
[ 35.216023] eth0: no IPv6 routers present

I don't have any special network configuration, just plain old DHCP on ethernet. I don't have any other network issues and other networked services such as Apache don't terminate like this.

Also why does service say it is running when it isn't? If I run this "service tftpd-hpa status ; ps aux | grep tftpd" I get"
tftpd-hpa start/running
root 3328 0.0 0.0 9384 936 pts/2 S+ 20:28 0:00 grep --color=auto tftpd

 I've added "service tftpd-hpa restart" to /etc/rc/local but doesn't work either (I just get the error message twice)

Anything else I can try to make tftpd-hpa work from boot?

Thanks
Allen

Revision history for this message
Diego Morales (dgmorales) wrote :

> Also why does service say it is running when it isn't?
Yeah, I saw the same thing. Didn't investigate it enough to make any comments.

> Anything else I can try to make tftpd-hpa work from boot?
Maybe starting tftpd as an "up" line on the interface definition
(/etc/network/interface, man interfaces for more info).

Revision history for this message
AllenS (thehousecat) wrote :

Hi Diego

I added "service tftpd-hpa restart" as an "up" line to eth0 and it worked! Thank you very much.

But even better still you pointed me in the right direction to get to the bottom of the problem. My interface file looked like this:

# The primary network interface
auto eth0
#up service tftpd-hpa restart
#NetworkManager#iface eth0 inet dhcp

I moved the "iface eth0 inet dhcp" bit onto a new line and tftpd-hpa now works perfectly from boot. I don't know how the "interface" file got screwed up like that because I hadn't touched until you mentioned it.

To be fair I installed this system with a daily build of precise around the time of beta 2, so perhaps that's why.

Anyway all working now so thanks again for the help.

Allen

Revision history for this message
Mark Favas (mark-favas) wrote :

I have the same problem on 12.04.1 with tftpd-hpa version 5.2-1ubuntu1.

I have a single interface, eth0, which gets its address via DHCP. On boot, tftpd-hpa fails to start with the "cannot resolve local IPv4 bind address:0.0.0.0".

 "sudo status tftpd-hpa" returns "tftpd-hpa start/running", but with no "process xxxx" reported.

"sudo restart tftpd-hpa" successfully restarts the daemon, and now "sudo status tftpd-hpa" returns "tftpd-hpa start/running, process 16083".

Mark

Revision history for this message
Bambang Pranoto (bpranoto) wrote :

I also have the same problem on 12.04.1.

My workaround is putting a new script /etc/network/if-up.d/tftpd-hpa which contains:

#!/bin/sh
restart tftpd-hpa

Of course don't forget to chmod 755 the script.

Revision history for this message
Dave Walker (davewalker) wrote :

Can those that have reported this issue post 12.04, please confirm if they are running Ubuntu Desktop or Ubuntu Server please?

Thanks

Revision history for this message
Bambang Pranoto (bpranoto) wrote :

I run Ubuntu Desktop.

Revision history for this message
DrKay (dr-jameskay) wrote :

I'm running Ubuntu Desktop with the LTPS packages installed (64-bit).

Revision history for this message
Dave Walker (davewalker) wrote :

Yes, on a Desktop - the service starts before network-manager has
brought the network up.

Revision history for this message
DrKay (dr-jameskay) wrote :

The workaround in #30 worked for me.

Revision history for this message
Steven Hill (steven-5) wrote :

I'm running Ubuntu 12.04 LTS Desktop in Virtual Box and this problem wasted a whole day for me (I'm pretty new to Linux) until I ran into this site. Workaround #30 worked for me...

Revision history for this message
Omer Siar (omer-baysal) wrote :

It affects me on Lubuntu 13.04 Desktop, The workaround in #30 DID NOT work for me

Revision history for this message
Martin Pagh Goodwin (martin-goodwin-e) wrote :

It affects me on Kubuntu 13.10 Desktop. I manually restart the service at the command line (sudo service tftp-hpa restart)

Revision history for this message
murzzz (murzzz) wrote :

Still happens for me on Ubuntu 14.04.
Workaround in comment #30 helped, thanks.

Revision history for this message
Richard Sarkis (damnedfacts) wrote :

This also affects in in Ubuntu 14.04, I followed the suggestions in comment #13.

I replace the line "start on runlevel [2345]" in /etc/init/tftpd-hpa.conf with "start on (filesystem and net-device-up IFACE!=lo)" and now it starts on boot.

I'm not sure why but I didn't have this problem with Ubuntu 12.04.

Revision history for this message
Tal Liron (emblem-parade) wrote :

Richard Sarkis is exactly correct: the problem exists in 14.04, and his solution works. The problem indeed did not exist in 12.04.

Revision history for this message
Oleksij Rempel (olerem) wrote :

All users of 14.04. Please mark "This bug affect me" on a new report https://bugs.launchpad.net/ubuntu/+source/tftp-hpa/+bug/1342580

Mathew Hodson (mhodson)
no longer affects: ltsp (Ubuntu Lucid)
no longer affects: ltsp (Ubuntu)
Changed in tftp-hpa (Ubuntu):
milestone: ubuntu-10.04-beta-2 → none
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.