9

I have Ubuntu 10.04 server currently setup with dhcp3-server as well as a bridged interface (br0) for use with virtual machines. The problem I have is that when the server reboots, dhcp3-server fails to load because of the extra delay caused by bringing up the bridged interface.

Essentially br0 doesn't have an IP address for use with DHCP3-Server until late in the boot cycle, well after DHCP3-server has attempted to load.

Once the server has booted I can run '/etc/init.d/dhcp3-server start' without any issue.

Is there any way I can either: - Force dhcp3-server to wait until the interface has loaded before attempting to load? - Start dhcp3-server after everything else has loaded up?

2 Answers 2

11

One solution is to tell the dhcp-server not to start automatically and then add the following two lines to you /etc/network/interfaces file for you bridge definition

post-up /etc/init.d/dhcp3-server start
pre-down /etc/init.d/dhcp3-server stop

So it will end up looking like this

iface br0 inet static
    bridge_ports eth0 eth1
    address 192.168.1.2
    broadcast 192.168.1.255
    netmask 255.255.255.0
    gateway 192.168.1.1
    post-up /etc/init.d/dhcp3-server start
    pre-down /etc/init.d/dhcp3-server stop

This way the network management (ifup/ifdown, NOT network-manager) will start the DHCP server after bringing up the bridge, and shut it down before removing the bridge.

2
  • I have tested both answers and this post-up / pre-down solution is much much cleaner and upgrade friendly. Thanks heaps for the great suggestions! I searched high and low for a simple solution like this one
    – user2009
    Sep 11, 2010 at 5:45
  • My pleasure ;) its always great to be appreciated. Sep 11, 2010 at 12:05
2

You could modify the /etc/init.d/dhcp3-server startup script to wait for an IP address to be available on br0. For instance: (Warning: untested code!)

# wait 5 secs between br0-ready tests
wait_time_between_probes=5
# maximum number of attempts (i.e., timeout)
max_attempts=10

log_progress_msg "Waiting for br0 to get an IP address"
for n in $(seq 1 $max_attempts); do
  if /sbin/ifconfig br0 | egrep -q "inet addr:" ; then
    # IP address ready on br0, exit loop
    break
  else
    sleep $wait_time_between_probes
  fi
done
if [ "$n" = "$max_attempts" ]; then
    log_warning_msg "Maximum number of attempts reached, but br0 has no IP address yet" 
    log_warning_msg "Continuing anyway but DHCP3 server might not start correctly"
fi 

The snippet should go into the startup script, within the case ... start) part, before startup of the DHCP3 daemon. Of course, you should tune the wait time and number of attempts to match your environment (how long does it take maximum for br0 to get the IP address?)

6
  • This is definitely on the right track. I placed this imediately after "case "$1" in start)" in "/etc/init.d/dhcp3-server" however the condition "/sbin/ifconfig br0 | fgrep -q "addr:"" seems to succeed even without the bridge interface online. Typing "/sbin/ifconfig br0 | fgrep -q "addr:"" in to terminal gives no output.
    – user2009
    Sep 8, 2010 at 10:46
  • Also although trivial the two 'log_warning_msg' at the end of the script will show regardless of success and failure. would they be better inside the log with a if (max_attempts=n) style statement to correctly show these messages on failure?
    – user2009
    Sep 8, 2010 at 10:46
  • Also the bridge interface normal takes an additional 5 - 10 seconds after the interfaces load to establish, just long enough for dhcp3-server to fail.
    – user2009
    Sep 8, 2010 at 10:49
  • @user2009 Concerning the grep -q line: 1. I think the match fails because the bridge acquires an IPv6 address as soon as it's up. If you're only interested in IPv4 address, just replace the grep line by grep -q 'inet addr:' (already done above); otherwise, a more complex regular expression needs to be found, that matches all possible final IP addresses of your bridge. 2. The -q option suppresses output (just like > /dev/null) Sep 8, 2010 at 15:28
  • @user2009 thanks for the comment on log_warning_msg; I think I've fixed it according to your suggestion Sep 8, 2010 at 15:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .