dhcp3 fails to start during boot-time but starts seamlessly invoking the init-script manually

[jan_k]

The dhcpd of dhcp3-server does not start up on bootup. It fails in case 3 of the check_status function after it invoked the start-stop-daemon.

I don't know exactly what the "if read pid < "$DHCPDPID .." does though. Anyway, it's a case where the pid-file has been created but the process is non-existend.

Now the oddity. Run from the shell it works seamlessly.

I have no idea what causes this. I checked permissions, reinstalled, whatever.

One possibility is that it is somehow dependant on the INTERFACES variable. That it fails because one of the specified devices isn't up yet. But there's no suspicious output from the dhcpd in the logs.

My configuration is:

ddns-update-style interim;
ddns-domainname "home";

option domain-name "home";

default-lease-time 3600; # seconds
max-lease-time 7200; # seconds

log-facility local7;

# for now, accept them
# deny unknown-clients;

# Wired network
subnet 192.168.128.0 netmask 255.255.255.0 {
  range 192.168.128.11 192.168.128.254;
  option subnet-mask 255.255.255.0;
  option routers 192.168.128.1;
  option broadcast-address 192.168.128.255;
  option domain-name-servers 192.168.128.1;
}

# Wireless network
subnet 192.168.129.0 netmask 255.255.255.0 {
  range 192.168.129.11 192.168.129.254;
  option subnet-mask 255.255.255.0;
  option routers 192.168.129.1;
  option broadcast-address 192.168.129.255;
# NOTE: different subnet!
  option domain-name-servers 192.168.128.1;
}

The /etc/default/dhcp3-server is:

INTERFACES="eth0 ath0"

The ifconfig -a output is:

ath0 Link encap:Ethernet HWaddr 00:14:78:70:D6:96
          inet addr:192.168.129.1 Bcast:192.168.129.255 Mask:255.255.255.0
          inet6 addr: fe80::214:78ff:fe70:d696/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b) TX bytes:468 (468.0 b)

eth0 Link encap:Ethernet HWaddr 00:80:AD:78:B3:5B
          inet addr:192.168.128.1 Bcast:192.168.128.255 Mask:255.255.255.0
          inet6 addr: fe80::280:adff:fe78:b35b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:2511 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3304 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:278108 (271.5 KiB) TX bytes:2657761 (2.5 MiB)
          Interrupt:10 Base address:0xe800

eth1 Link encap:Ethernet HWaddr 00:00:1C:D5:FA:CE
          inet6 addr: fe80::200:1cff:fed5:face/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:2926 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2123 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2613788 (2.4 MiB) TX bytes:238198 (232.6 KiB)
          Interrupt:5 Base address:0x8000

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:4530 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4530 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:422574 (412.6 KiB) TX bytes:422574 (412.6 KiB)

ppp0 Link encap:Point-to-Point Protocol
          inet addr:80.146.127.186 P-t-P:217.0.116.129 Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
          RX packets:2760 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1951 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:2543012 (2.4 MiB) TX bytes:184747 (180.4 KiB)

sit0 Link encap:IPv6-in-IPv4
          NOARP MTU:1480 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.130.1 P-t-P:192.168.130.2 Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

wifi0 Link encap:UNSPEC HWaddr 00-14-78-70-D6-96-61-74-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:277
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:199
          RX bytes:396 (396.0 b) TX bytes:3050 (2.9 KiB)
          Interrupt:12 Memory:d4980000-d4990000

The dhcp.log is free of errors. dhcpd -.t returns no errors.

I hope this is of any help. This is extremely annyoing...

[jan_k (wobble-gmx)]

One more thing I just noticed:

After the "--" mark in the commandline of start-stop-daemon "-pf" and "-q" is used but I do not see those options documented in man dhcpd3.

[KarlGoetz (kgoetz)]

I have a similar problem on a 6.06.1 server - the issue revolves around wether the server was shut down or cut (ie power failure).
if it shuts down, dhcpd will start fine. if its cut (or otherwise not shut down properly) dhcpd fails to start on boot. I havent investigated the cause though (i have no idea what i'm looking for).

[bENch (bench-inc-co)]

i had the same problem on debian...and you are right.... edit your network interface file and set ethx (the network card on which dhcp listens on) that it will start on boot time

hope this helps you

[KarlGoetz (kgoetz)]

I think this counts as confirmed, perhaps it will mean it gets fixed faster ;)

[HonoredMule (honoredmule)]

A VERY annoying bug indeed. About once every 1-3 weeks, I have to log into my server to start dhcp3-server when some desktop's lease expires and I realize it never got started or quit silently. I added '/etc/init.d/dhcp3-server restart' to my gateway setup script, but that drastically slows the execution of the script which is also responsible for manually resetting the PPPoE connection.

[hagan (hagn)]

I see the same problem here on my machine. The problem is dhcpd depends on a configured interface to listen on, but the interfaces are handled by the network-manager which is started after dhcpd in the standard setup. Even if I put dhcpd after network-manager in the startup scripts, it takes so long to configure the interfaces that dhcpd is still too fast. I do not know how to only start dhcpd after the interfaces are up. Is there a possibility in network-manager to start up services after interfaces are configured?

[hagan (hagn)]

I forgot too mention, that I am running Jaunty Desktop install

[Ian Justman (ianj)]

My fix for dhcp3 starting on power-up is to chgrp the /etc/dhcp3 directory to dhcpd, then it works. Won't work for everyone, but for me, since the box is only a DHCP server, it's fine.

The error that flies by but it says that it can't read the config file. That's because the directory is owned by root:root and is set to 750, so you gotta be root or in group root to see what's in that directory.

A possible solution in case both client and server need access is to put the "dhcp" and "dhcpd" users into the root group. The idea is to make sure that both users SOMEhow have access to that directory.

--Ian.

[Wolfram Gloger (bugzilla1)]

I hit this issue today, on karmic. dhcpd _sometimes_ fails to start on manually configured interfaces.

IMHO this happens because there is a race between the "new" /etc/init/networking.conf from upstart/ifupdown and the "old" /etc/rc2.d/S40dhcp3-server. Nothing makes sure that networking is fully up before the start-scripts for (e.g.) runlevel 2 are started (in former times, this was of course guaranteed by the sysinit scripts). The appended patch makes sure that all multi-user runlevel scripts are executed only after networking (ifup -a) has completed.

I think this bug could also affect other services with only sysvinit-compatible start scripts.

[kschmitt (kyleaschmitt)]

I was just entering a bug for this, and it ended up being a duplicate.

The issue is the permissions on the rndc.key (/etc/dhcp3/rndc.key).
If the dhcpd user can't read it, the dhcp3-server fails to start on boot, but still starts later if called from /etc/init.d or using the service command.

This almost looks like more of a problem with the init system, but I'm not sure.