Description of problem: systemctl status dhcpd.service: dhcpd.service - DHCPv4 Server Daemon Loaded: loaded (/usr/lib/systemd/system/dhcpd.service; enabled) Active: failed (Result: exit-code) since Thu 2015-01-01 21:41:47 CET; 4min 59s ago Process: 1646 ExecStart=/usr/sbin/dhcpd -pf /run/dhcpd/dhcpd.pid -cf $CONFIGFILE -lf $LEASEFILE $OPTIONS $INTERFACES (code=exited, status=1/FAILURE) Jan 01 21:41:47 windbox.astronomy dhcpd[1646]: Not configured to listen on any interfaces! However, it starts fine by systemctl start dhcpd.service after the boot. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
I've noticed that Fedora has changed network.target to network-online.target in their service files (and also added this as a Wants and not just an After). Do we need to do the same in Cauldron, or should this work as-is? Also, they've gotten rid of the use of PID files and change the service types from forking to notify.
CC: (none) => mageia, pterjan
dhcpd IS running after a boot in cauldron. What is the difference between mga4 and cauldron in that respect?
Correction: dhcpd is only running after a boot if there is an active link on the port, like a switch. Otherwise the interface has to be brought up with ifup before dhcpd can be started.
I think this is INVALID. I am already running DHCP servers with Mageia 4 just fine. I just set up a test instance in Cauldron and it works fine too.
Status: NEW => RESOLVEDResolution: (none) => INVALID
It certainly is NOT invalid for my box running mga4. dhcpd is not running after a reboot. I have to start it with "systemctl start dhcpd.service" or by using the MCC. It is true that dhcpd starts fine on another machine running cauldron. I should mention that mga4 is a net-upgrade from mga3, a major advantage as the box is hidden in an inconvenient place for a fresh install (it is my connection to the outside world). It looks to me as if the interface has not yet come up when the dhcpd is started. I can dig out the log, if it is needed as evicence. I have seen it flashing on the screen during a boot.
Could you add the output from: systemctl status dhcpd.service journalctl -bu dhcpd.service cat /etc/sysconfig/dhcpd cat /etc/dhcpd.conf all run as root after a fresh boot? Might need to get more debug info from you after that :)
Status: RESOLVED => REOPENEDResolution: INVALID => (none)
Net device: eth0 MCC setup LAN on eth1 re-boot Check Services (in MCC): dhcpd stopped. systemctl status dhcpd.service: dhcpd.service - DHCPv4 Server Daemon Loaded: loaded (/usr/lib/systemd/system/dhcpd.service; enabled) Active: failed (Result: exit-code) since Wed 2015-01-07 10:51:54 CET; 6min ago Process: 1647 ExecStart=/usr/sbin/dhcpd -pf /run/dhcpd/dhcpd.pid -cf $CONFIGFILE -lf $LEASEFILE $OPTIONS $INTERFACES (code=exited, status=1/FAILURE) Jan 07 10:51:54 windbox.astronomy dhcpd[1647]: to which interface eth1 is attached. ** Jan 07 10:51:54 windbox.astronomy dhcpd[1647]: Not configured to listen on any interfaces! Jan 07 10:51:54 windbox.astronomy systemd[1]: dhcpd.service: control process exited, code=exited status=1 Jan 07 10:51:54 windbox.astronomy systemd[1]: Failed to start DHCPv4 Server Daemon. Jan 07 10:51:54 windbox.astronomy systemd[1]: Unit dhcpd.service entered failed state. journalctl -b -u dhcpd.service: -- Logs begin at Wed 2014-08-06 06:20:56 CEST, end at Wed 2015-01-07 10:58:56 CET. -- Jan 07 10:51:53 windbox.astronomy systemd[1]: Starting DHCPv4 Server Daemon... Jan 07 10:51:54 windbox.astronomy dhcpd[1647]: Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file Jan 07 10:51:54 windbox.astronomy dhcpd[1647]: Wrote 11 leases to leases file. Jan 07 10:51:54 windbox.astronomy dhcpd[1647]: Jan 07 10:51:54 windbox.astronomy dhcpd[1647]: No subnet declaration for eth1 (no IPv4 addresses). Jan 07 10:51:54 windbox.astronomy dhcpd[1647]: ** Ignoring requests on eth1. If this is not what Jan 07 10:51:54 windbox.astronomy dhcpd[1647]: you want, please write a subnet declaration Jan 07 10:51:54 windbox.astronomy dhcpd[1647]: in your dhcpd.conf file for the network segment Jan 07 10:51:54 windbox.astronomy dhcpd[1647]: to which interface eth1 is attached. ** Jan 07 10:51:54 windbox.astronomy dhcpd[1647]: Not configured to listen on any interfaces! Jan 07 10:51:54 windbox.astronomy systemd[1]: dhcpd.service: control process exited, code=exited status=1 Jan 07 10:51:54 windbox.astronomy systemd[1]: Failed to start DHCPv4 Server Daemon. Jan 07 10:51:54 windbox.astronomy systemd[1]: Unit dhcpd.service entered failed state. cat /etc/sysconfig/dhcpd OPTIONS="-q" INTERFACES="eth1" INTERFACES="eth1" INTERFACES="eth1" INTERFACES="eth1" INTERFACES="eth1" INTERFACES="eth1" INTERFACES="eth1" INTERFACES="eth1" INTERFACES="eth1" INTERFACES="eth1" cat /etc/dhcpd.conf subnet 192.168.5.0 netmask 255.255.255.0 { # default gateway option routers 192.168.5.1; option subnet-mask 255.255.255.0; option domain-name "192.168.1.1"; option domain-name-servers 192.168.1.1; range dynamic-bootp 192.168.5.100 192.168.5.253; default-lease-time 430000; max-lease-time 432000; } And now I can start it by systemctl start dhcpd.service I do not see any strange problems.
Hmm, very odd. Can you also supply a "systemctl status network.service" and "journalctl -bu network.service" from the same boot? I want to compare the timestamps from the logs to see when the network was supposedly setup. It certainly appears as if dhcpd is started before the network is fully initialised, even although it has After=network.target defined in it. FWIW, I don't have any "INTERFACES=" lines in my sysconfig/dhcpd file and it just "works it out" from the subnet definitions automatically, but I don't think this would matter in your case.
systemctl status network.service: network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: active (running) since Wed 2015-01-07 10:51:50 CET; 2h 16min ago Process: 825 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=0/SUCCESS) CGroup: /system.slice/network.service ââ1233 /sbin/ifplugd -I -b -i eth0 ââ1293 /sbin/ifplugd -I -b -i eth1 ââ1469 dhclient -1 -q -lf /var/lib/dhclient/dhclient--eth0.lease -pf /var/run/dhclient-eth0.pid eth0 Jan 07 11:43:47 windbox.astronomy dhclient[1469]: bound to 192.168.1.100 -- renewal in 1608 seconds. Jan 07 12:10:35 windbox.astronomy dhclient[1469]: DHCPREQUEST on eth0 to 192.168.1.1 port 67 Jan 07 12:10:35 windbox.astronomy dhclient[1469]: DHCPACK from 192.168.1.1 Jan 07 12:10:35 windbox.astronomy dhclient[1469]: bound to 192.168.1.100 -- renewal in 1352 seconds. Jan 07 12:33:07 windbox.astronomy dhclient[1469]: DHCPREQUEST on eth0 to 192.168.1.1 port 67 Jan 07 12:33:07 windbox.astronomy dhclient[1469]: DHCPACK from 192.168.1.1 Jan 07 12:33:08 windbox.astronomy dhclient[1469]: bound to 192.168.1.100 -- renewal in 1514 seconds. Jan 07 12:58:22 windbox.astronomy dhclient[1469]: DHCPREQUEST on eth0 to 192.168.1.1 port 67 Jan 07 12:58:22 windbox.astronomy dhclient[1469]: DHCPACK from 192.168.1.1 Jan 07 12:58:23 windbox.astronomy dhclient[1469]: bound to 192.168.1.100 -- renewal in 1769 seconds. journalctl -bu network.service: -- Logs begin at Wed 2014-08-06 06:20:56 CEST, end at Wed 2015-01-07 13:10:22 CET. -- Jan 07 10:51:39 windbox.astronomy systemd[1]: Starting LSB: Bring up/down networking... Jan 07 10:51:40 windbox.astronomy systemd-sysctl[863]: Overwriting earlier assignment of kernel/sysrq in file '/etc/sysctl.d/51-alt-sysrq.conf'. Jan 07 10:51:41 windbox.astronomy network[825]: Bringing up loopback interface: 127.0.0.1 Jan 07 10:51:49 windbox.astronomy network[825]: squid.service - LSB: Starts the squid daemon Jan 07 10:51:49 windbox.astronomy network[825]: Loaded: loaded (/etc/rc.d/init.d/squid) Jan 07 10:51:49 windbox.astronomy network[825]: Active: inactive (dead) Jan 07 10:51:49 windbox.astronomy network[825]: squid: ERROR: No running copy Jan 07 10:51:49 windbox.astronomy network[825]: [ OK ] Jan 07 10:51:49 windbox.astronomy network[825]: Enabling IPv4 packet forwarding [ OK ] Jan 07 10:51:50 windbox.astronomy ifplugd(eth0)[1233]: ifplugd 0.28 initializing. Jan 07 10:51:50 windbox.astronomy ifplugd(eth0)[1233]: Using interface eth0/40:61:86:4F:CB:84 with driver <e1000e> (version: 2.3.2-k) Jan 07 10:51:50 windbox.astronomy ifplugd(eth0)[1233]: Using detection mode: SIOCETHTOOL Jan 07 10:51:50 windbox.astronomy ifplugd(eth0)[1233]: Initialization complete, link beat detected. Jan 07 10:51:50 windbox.astronomy ifplugd(eth0)[1233]: Executing '/etc/ifplugd/ifplugd.action eth0 up'. Jan 07 10:51:50 windbox.astronomy network[825]: Bringing up interface eth0: [ OK ] Jan 07 10:51:50 windbox.astronomy ifplugd(eth1)[1293]: ifplugd 0.28 initializing. Jan 07 10:51:50 windbox.astronomy network[825]: Bringing up interface eth1: [ OK ] Jan 07 10:51:50 windbox.astronomy ifplugd(eth1)[1293]: Using interface eth1/40:61:86:4F:CB:85 with driver <e1000e> (version: 2.3.2-k) Jan 07 10:51:50 windbox.astronomy ifplugd(eth1)[1293]: Using detection mode: SIOCETHTOOL Jan 07 10:51:50 windbox.astronomy ifplugd(eth1)[1293]: Initialization complete, link beat not detected. Jan 07 10:51:50 windbox.astronomy systemd-sysctl[1327]: Overwriting earlier assignment of kernel/sysrq in file '/etc/sysctl.d/51-alt-sysrq.conf'. Jan 07 10:51:50 windbox.astronomy systemd[1]: Started LSB: Bring up/down networking. Jan 07 10:51:51 windbox.astronomy dhclient[1318]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Jan 07 10:51:51 windbox.astronomy dhclient[1318]: DHCPACK from 192.168.1.1 Jan 07 10:51:52 windbox.astronomy ifplugd(eth0)[1233]: client: Determining IP information for eth0... done. Jan 07 10:51:52 windbox.astronomy ifplugd(eth0)[1233]: client: 192.168.1.100 Jan 07 10:51:52 windbox.astronomy ifplugd(eth0)[1233]: client: squid.service - LSB: Starts the squid daemon Jan 07 10:51:52 windbox.astronomy ifplugd(eth0)[1233]: client: Loaded: loaded (/etc/rc.d/init.d/squid) Jan 07 10:51:52 windbox.astronomy ifplugd(eth0)[1233]: client: Active: inactive (dead) Jan 07 10:51:52 windbox.astronomy ifplugd(eth0)[1233]: client: squid: ERROR: No running copy Jan 07 10:51:52 windbox.astronomy ifplugd(eth0)[1233]: Program executed successfully. Jan 07 10:51:54 windbox.astronomy ifplugd(eth1)[1293]: Link beat detected. Jan 07 10:51:55 windbox.astronomy ifplugd(eth1)[1293]: Executing '/etc/ifplugd/ifplugd.action eth1 up'. Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: 192.168.5.1 Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: squid.service - LSB: Starts the squid daemon Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Loaded: loaded (/etc/rc.d/init.d/squid) Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Active: active (running) since Wed 2015-01-07 10:51:56 CET; 1s ago Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Process: 1727 ExecStart=/etc/rc.d/init.d/squid start (code=exited, status=0/SUCCESS) Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Main PID: 1788 (squid) Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: CGroup: /system.slice/squid.service Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: ââ1786 squid Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: ââ1788 (squid-1) Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: ââ1820 (logfile-daemon) /var/log/squid/access.log Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: ââ1821 (unlinkd) Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: ââ1822 diskd 1830916 1830917 1830918 Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: ââ1823 (pinger) Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Jan 07 10:51:55 windbox.astronomy systemd[1]: Starting LSB: Starts the squid daemon... Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Jan 07 10:51:55 windbox.astronomy squid[1757]: Squid Parent: will start 1 kids Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Jan 07 10:51:55 windbox.astronomy squid[1757]: Squid Parent: (squid-1) process 1759 started Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Jan 07 10:51:55 windbox.astronomy squid[1786]: Squid Parent: will start 1 kids Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Jan 07 10:51:55 windbox.astronomy squid[1786]: Squid Parent: (squid-1) process 1788 started Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Jan 07 10:51:56 windbox.astronomy squid[1757]: Squid Parent: (squid-1) process 1759 exited with status 0 Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Jan 07 10:51:56 windbox.astronomy squid[1727]: init_cache_dir ... Starting squid: .[ OK ] Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Jan 07 10:51:56 windbox.astronomy systemd[1]: squid.service: Supervising process 1788 which is not our child. We'll most likely not notice when it exits. Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Jan 07 10:51:56 windbox.astronomy systemd[1]: Started LSB: Starts the squid daemon. Jan 07 10:51:58 windbox.astronomy ifplugd(eth1)[1293]: client: Reloading Squid Jan 07 10:51:59 windbox.astronomy ifplugd(eth1)[1293]: Program executed successfully. Jan 07 11:17:25 windbox.astronomy dhclient[1469]: DHCPREQUEST on eth0 to 192.168.1.1 port 67 Jan 07 11:17:25 windbox.astronomy dhclient[1469]: DHCPACK from 192.168.1.1 Jan 07 11:17:25 windbox.astronomy dhclient[1469]: bound to 192.168.1.100 -- renewal in 1582 seconds. Jan 07 11:43:47 windbox.astronomy dhclient[1469]: DHCPREQUEST on eth0 to 192.168.1.1 port 67 Jan 07 11:43:47 windbox.astronomy dhclient[1469]: DHCPACK from 192.168.1.1 Jan 07 11:43:47 windbox.astronomy dhclient[1469]: bound to 192.168.1.100 -- renewal in 1608 seconds. Jan 07 12:10:35 windbox.astronomy dhclient[1469]: DHCPREQUEST on eth0 to 192.168.1.1 port 67 Jan 07 12:10:35 windbox.astronomy dhclient[1469]: DHCPACK from 192.168.1.1 Jan 07 12:10:35 windbox.astronomy dhclient[1469]: bound to 192.168.1.100 -- renewal in 1352 seconds. Jan 07 12:33:07 windbox.astronomy dhclient[1469]: DHCPREQUEST on eth0 to 192.168.1.1 port 67 Jan 07 12:33:07 windbox.astronomy dhclient[1469]: DHCPACK from 192.168.1.1 Jan 07 12:33:08 windbox.astronomy dhclient[1469]: bound to 192.168.1.100 -- renewal in 1514 seconds. Jan 07 12:58:22 windbox.astronomy dhclient[1469]: DHCPREQUEST on eth0 to 192.168.1.1 port 67 Jan 07 12:58:22 windbox.astronomy dhclient[1469]: DHCPACK from 192.168.1.1 Jan 07 12:58:23 windbox.astronomy dhclient[1469]: bound to 192.168.1.100 -- renewal in 1769 seconds. I read "link beat not detected", but eth1 is connected to a switch. But maybe this does not matter?
Ahh I see the problem. You're using ifplugd on your (static) eth1 device. This means that the initialisation is delayed until a link-beat is detected. This is not really recommended for static networks where this is the server as it really shouldn't be doing any hotplug stuff (as it leads to problems like this). Just set: MII_NOT_SUPPORTED=yes in: /etc/sysconfig/network-scripts/ifcfg-eth1 (or use a GUI - I think it's supported via the tools) and you should be good.
It worked. Thank you.
OK, so this is somewhat expected behaviour then. dhcpd cannot really cope with hotplug networks so things have to be configured appropriately. Thanks for debugging it :)
Status: REOPENED => RESOLVEDResolution: (none) => WORKSFORME
Hi Colin The problem is back. Maybe I should not have updated to systemd-208-10.6.mga4. But the problem needs to be resolved. dhcpd is not running after a reboot. journalctl -u -b dhcpd.service: .... Jan 22 22:06:15 windbox.astronomy dhcpd[711]: No subnet declaration for eth1 (no IPv4 addresses). Jan 22 22:06:15 windbox.astronomy dhcpd[711]: ** Ignoring requests on eth1. Jan 22 22:06:15 windbox.astronomy dhcpd[711]: Not configured to listen on any interfaces! Exactly as before: I can start it manually by systemctl start dhcpd.service It looks as if there are problems getting eth1 up and running. journalctl -u -b network.service: Jan 22 22:06:13 windbox.astronomy systemd[1]: Starting LSB: Bring up/down networking... Jan 22 22:06:13 windbox.astronomy systemd-sysctl[993]: Overwriting earlier assignment of kernel/sysrq in file '/etc/sysctl.d/51-alt-sysrq.conf'. Jan 22 22:06:18 windbox.astronomy network[902]: Bringing up loopback interface: 127.0.0.1 Jan 22 22:06:27 windbox.astronomy network[902]: squid.service - LSB: Starts the squid daemon Jan 22 22:06:27 windbox.astronomy network[902]: Loaded: loaded (/etc/rc.d/init.d/squid) Jan 22 22:06:27 windbox.astronomy network[902]: Active: inactive (dead) Jan 22 22:06:27 windbox.astronomy network[902]: squid: ERROR: No running copy Jan 22 22:06:27 windbox.astronomy network[902]: [ OK ] Jan 22 22:06:27 windbox.astronomy network[902]: Enabling IPv4 packet forwarding [ OK ] Jan 22 22:06:30 windbox.astronomy NET[2192]: /etc/sysconfig/network-scripts/ifup-post : updated /etc/resolv.conf Jan 22 22:06:31 windbox.astronomy network[902]: Bringing up interface eth0: 192.168.1.100 Jan 22 22:06:31 windbox.astronomy network[902]: squid.service - LSB: Starts the squid daemon Jan 22 22:06:31 windbox.astronomy network[902]: Loaded: loaded (/etc/rc.d/init.d/squid) Jan 22 22:06:31 windbox.astronomy network[902]: Active: inactive (dead) Jan 22 22:06:31 windbox.astronomy network[902]: squid: ERROR: No running copy Jan 22 22:06:31 windbox.astronomy network[902]: [ OK ] Jan 22 22:06:33 windbox.astronomy network[902]: Bringing up interface eth1: 192.168.5.1 Jan 22 22:06:33 windbox.astronomy network[902]: squid.service - LSB: Starts the squid daemon Jan 22 22:06:33 windbox.astronomy network[902]: Loaded: loaded (/etc/rc.d/init.d/squid) Jan 22 22:06:33 windbox.astronomy network[902]: Active: inactive (dead) Jan 22 22:06:34 windbox.astronomy network[902]: squid: ERROR: No running copy Jan 22 22:06:34 windbox.astronomy network[902]: [ OK ] Jan 22 22:06:34 windbox.astronomy systemd-sysctl[2416]: Overwriting earlier assignment of kernel/sysrq in file '/etc/sysctl.d/51-alt-sysrq.conf'. Jan 22 22:06:34 windbox.astronomy systemd[1]: Started LSB: Bring up/down networking.
Status: RESOLVED => REOPENEDResolution: WORKSFORME => (none)
Above, it looks as if network, dhcpd and squid start at the same time. I have returnet to systemd-208-10.5.mga4 et al. The start-up sequence is now: network -> dhcpd -> squid. I have also checked the start-up sequence in cauldron/mga5. It is again network -> dhcpd -> squid. There is something completely wrong with systemd-208-10.6.mga4 et al.
OK, that's certainly interesting to know. I've not yet been able to test the 10.6 version as was waiting for it to hit the build system. Will be looking into it shortly. Will make sure to test this better. In here it looks as if there is some confusion as squid seems to be being started as part of the network scripts... which is really odd. I take it a journalctl -b -u network doesn't make any reference to squid normally on 208-10.5?
Anyway, this problem is solved, 10.6 version is not released to the public as it's in it's testing phase. I'll open a new bug shortly for new systemd version and would apprecate any testing on it once I've resolved this immediate issue (need to get a few machines running it first and do my own tests tho') Will ping back here when I have it :)
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
Correct resolution.
Resolution: FIXED => WORKSFORME
Colin, There seems to be a more general problem with the start-up timings of old-style and systemd services which is NOT confined to version 10.6. I find this for 10.5: journalctl -b -u network.service -- Logs begin at Sun 2014-09-14 10:40:42 CEST, end at Sun 2015-01-25 09:09:40 CET. -- Jan 25 08:59:06 windbox.astronomy systemd[1]: Starting LSB: Bring up/down networking... Jan 25 08:59:07 windbox.astronomy systemd-sysctl[876]: Overwriting earlier assignment of kerne Jan 25 08:59:09 windbox.astronomy network[834]: Bringing up loopback interface: 127.0.0.1 Jan 25 08:59:16 windbox.astronomy network[834]: squid.service - LSB: Starts the squid daemon Jan 25 08:59:16 windbox.astronomy network[834]: Loaded: loaded (/etc/rc.d/init.d/squid) Jan 25 08:59:16 windbox.astronomy network[834]: Active: inactive (dead) Jan 25 08:59:16 windbox.astronomy network[834]: squid: ERROR: No running copy Jan 25 08:59:16 windbox.astronomy network[834]: [ OK ] Jan 25 08:59:16 windbox.astronomy network[834]: Enabling IPv4 packet forwarding [ OK ] Jan 25 08:59:19 windbox.astronomy network[834]: Bringing up interface eth0: 192.168.1.100 Jan 25 08:59:19 windbox.astronomy network[834]: squid.service - LSB: Starts the squid daemon Jan 25 08:59:19 windbox.astronomy network[834]: Loaded: loaded (/etc/rc.d/init.d/squid) Jan 25 08:59:19 windbox.astronomy network[834]: Active: inactive (dead) Jan 25 08:59:19 windbox.astronomy network[834]: squid: ERROR: No running copy Jan 25 08:59:19 windbox.astronomy network[834]: [ OK ] Jan 25 08:59:22 windbox.astronomy network[834]: Bringing up interface eth1: 192.168.5.1 Jan 25 08:59:22 windbox.astronomy network[834]: squid.service - LSB: Starts the squid daemon Jan 25 08:59:22 windbox.astronomy network[834]: Loaded: loaded (/etc/rc.d/init.d/squid) Jan 25 08:59:22 windbox.astronomy network[834]: Active: inactive (dead) Jan 25 08:59:22 windbox.astronomy network[834]: squid: ERROR: No running copy Jan 25 08:59:22 windbox.astronomy network[834]: [ OK ] Jan 25 08:59:22 windbox.astronomy systemd-sysctl[1396]: Overwriting earlier assignment of kern Jan 25 08:59:22 windbox.astronomy systemd[1]: Started LSB: Bring up/down networking. squid.service - LSB: Starts the squid daemon many times until dhcp is ready. journalctl -b -u dhcpd.service -- Logs begin at Sun 2014-09-14 10:40:42 CEST, end at Sun 2015-01-25 09:09:40 CET. -- Jan 25 08:59:23 windbox.astronomy systemd[1]: Starting DHCPv4 Server Daemon... Jan 25 08:59:24 windbox.astronomy systemd[1]: Started DHCPv4 Server Daemon. And then there is the mandi daemon, that is started right after network in cauldron/mga, which makes it fail, so that shorewall not even try to start in a standard installation without any LAN.
Colin, This one is back again in mga5/cauldron after the update of dbus. (update of 20150210-235717). dhcpd DID start just before the update. After the re-boot it did not start because the network was not up.
Version: 4 => CauldronSource RPM: dhcp-server-4.2.5P1-2.mga4 or systemd-208-10.5.mga4? => dhcp-server
It turned out that dhcpd started just 2s before the LAN interface was up. As you suggested, I inserted MII_NOT_SUPPORTED=yes in the LAN interface, which is static and ethernet. I already inserted this line in the WiFi internet interface. I did not know that it was necessary for an ethernet connection! Everything is apparently hot-plugged, even if it is static.
The MII_NOT_SUPPORTED=yes should probably be on any interface that is acting as a DHCP server. Keep in mind that hotplug for wired ethernet means plugging/unplugging cables which you can easily do "on the move" and you need to react to them like any other hotplug thing. If you're a server, you either a) want to assume everything is static, or b) want to be super dynamic and react fully to that. Sadly for b) dhcpd as a daemon is not written that way - it makes too many assumptions about a static system and is unable to react dynamically as things change. So longer term, for the b) scenario the general approach for the future will be to use systemd-networkd which is very specifically designed to be hotplug friendly (everything is hotplug these days as you say!) and has a built in dhcp server to handle this situation (and for use in containers which can be thought of as a special case of a mini dynamic network contained within one machine!) Are you really acting as a DHCP server on your WiFi interface? This isn't a massively common setup. Anyway, I'm confused. This bug was originally about MGA4 and I remember debugging things on that distro. Now it seems to be changed to Cauldron. As the original problem was addressed I'm moving the back to MGA4 and marking it as solved again. If you see this problem on Cauldron, please open a new bug (it can reference the old bug, but it's certainly a new issue regardless from a management perspective (it doesn't matter too much here but it does in other workflows, so better to use the same approach generally!). It's also 100% unrelated to dbus update as this package does not factor in the critical path here. As before, when you open the new bug, can you attach the necessary debug as requested above, that would be great! Many thanks for helping to test this stuff. Much appreciated :)
Status: REOPENED => RESOLVEDVersion: Cauldron => 4Resolution: (none) => WORKSFORME
My use of a DHCP server was in lack of a box with 2 ethernet interfaces, and as all interfaces are hot plugged, it does not really matter. I have used a lot of time trying to understand why mandi some times gave a strange error that prevented shorewall from starting. This happened on a box without any subnet, just a plain PC connected to the internet. Both dhcpd and mandi are old-style SysV services, so it finally appeared to me that probably both problems are related to SysV startup in a hot-plugged environment. Both went away when I inserted MII_NOT_SUPPORTED=yes in all interfaces. There seems to be 2 solutions: a) Insert MII_NOT_SUPPORTED=yes in all interfaces. b) Start the SysV services manually after boot. in the case that they require the networks to be up.