Comment 5 for bug 125687

I was just going to report the same bug. I've seen this on Ubuntu Feisty, and I still see it on Gutsy. The problem I've seen seems to be that on DHCP client machines, it can take some time for network interfaces other than loopback to come up. The networking init script (which runs ifup -a) doesn't seem to wait for DHCP to finish getting an IP before letting later stuff run.

 This is a problem for programs which depend on specific interfaces existing. I have e.g. samba configured with
   interfaces = 127.0.0.1/8 10.255.255.255/8
   bind interfaces only = true

 so if those interfaces aren't up, nmbd doesn't start at all. smbd can start but only be listening on loopback because eth0 didn't have an IP when it started.

I hacked around it in the past once on a desktop I installed for a colleague with a script that waited for the network to come up:

--------
#!/bin/sh
# sleep long enough for networking to come up before ntp, firestarter, etc.

# /sbin/ifconfig

echo "waiting for network"
timeout=20
while ! /sbin/ifconfig | grep -q '129\.173';do
        sleep 1
        timeout=$(( $timeout - 1 ))
        if [ $timeout -lt 1 ];then
                echo "timeout waiting for network"
                return 1
        fi
done
echo "done waiting for network"
---------------

 I think I sourced it from some other init script, hence the return instead of exit.

 On my home server/desktop, which gets an IP via DHCP from my firewall/other server, I use /etc/rc.local as a convenient place to put
(sleep 60 && /etc/init.d/samba restart)&
 I have to say restart, not just start, because smbd can start bound to the loopback interface only, and "start" will just leave it running.

 Obviously these are not proper solutions, but I hope this helps understand the problem.

 I don't think I've seen the problem when I've changed /etc/network/interfaces to use a static IP for the machine.