I just reconfigured dhcpd.conf with an error. Then I ran "service dhcpd start" and was given the reply: "Starting dhcpd (via systemctl): [ OK ]" BUT actually it didn't start ok, and "service dhcpd status" shows that it did not. It should have printed: "Starting dhcpd (via systemctl): [ FAILED ]" [This isn't a problem in dhcpd; it's a bug in the integration of /sbin/service with systemd]
Colin, can you have a look at this one please? Assigning it to you for now.
Assignee: bugsquad => mageia
Blocks: (none) => 2120
Hmmm, I can't reproduce with another service. I'll have a look at dhcpd specifically.
Status: NEW => ASSIGNED
This looks like a problem specific to the dhcpd package to be honest, but I cannot immediately see what the problem is. There *is* a problem - the sysconfig file we use does not properly set the options actually used in the systemd unit, but that shouldn't cause this problem. I'll look into it, but systemctl start dhcpd.service is showing the same behaviour, so it's nothing to do with the service command (it's just passing you through to systemctl). Will assign to systemd for now... but it might still be a unit problem in dhcpd and I'm just being blind.
Source RPM: initscripts => systemd-43-5.mga2.src.rpm
OK, this is just a problem with dhcpd.service file. It seems this was copied form fedora where a similar bug exists. The -f or -d arguments cause the daemon not to fork, but the Type=simple (or rather the lack of any Type argument which means it defaults to simple) means that systemd pretty much just starts it and returns the shell before we even wait for the return of the command itself. It then later fails (this is a very small value of "later"). I'll rewrite the units and fix the bugs mentioned earlier.
Should be fixed in latest dhcp package. Please test and reopen of the problem persists.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXEDSource RPM: systemd-43-5.mga2.src.rpm => dhcp-4.2.3P2-2.mga2.src.rpm
Indeed, fixed. Thanks :-)