Bug 1035445

So running it manually works.

And what do you see if you do
# systemctl start dhcpd
(wait a moment)
# systemctl status dhcpd
?

If you see some more relevant info in 'journalctl -r' output post it here too.

as I indicated in my original submission, `systemctl start dhcpd' never returns to console (well, I waited 5 minutes), it just stays there. Here is output from another console, while `systemctl start dhcpd' is trying to startup:

[root@nas ~]# systemctl status dhcpd
dhcpd.service - DHCPv4 Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/dhcpd.service; disabled)
   Active: inactive (dead)
     Docs: man:dhcpd(8)
           man:dhcpd.conf(5)

[root@nas ~]# ps ax | grep dhcp
  422 ?        S      0:00 /sbin/dhclient -d -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-p37p1.pid -lf /var/lib/NetworkManager/dhclient-feed5bf5-2f88-7d33-96e3-79c6ac5d38c9-p37p1.lease -cf /var/lib/NetworkManager/dhclient-p37p1.conf p37p1
  983 pts/1    S+     0:00 systemctl start dhcpd
  995 pts/0    S+     0:00 grep --color=auto dhcp
[root@nas ~]#

oh, and /var/log/messages as well as journalctl are absolutely silent in regards to anything related to dhcpd, while attempt to start it is being made.

Looks like something it preventing dhcp from start - I guess it's likely some problem not in dhcp itself, but rather in NetworkManager or systemd subsystem.

Vlad, could you attach your dhcpd.conf ?

Lukáš, how can we debug this ?

log-facility local7;

subnet 192.168.0.0 netmask 255.255.255.0 {
  authoritative;
  option routers 192.168.0.1;
  option broadcast-address 192.168.0.255;
  option domain-name-servers 75.75.76.76,75.75.75.75,8.8.8.8;
  option ntp-servers 0.us.pool.ntp.org,1.us.pool.ntp.org;
  option ip-forwarding off;

  pool {
      range 192.168.0.64 192.168.0.192;
      default-lease-time 3600;
      max-lease-time 7200;
      deny known-clients;
   }
}

# bunch of hosts definition all using the following template:
host xxxxx {
  hardware ethernet 7c:2f:80:xx:xx:xx;
  fixed-address 192.168.0.101;
  option host-name "xxxxxx";
}

I don't have a problem running such configuration here.

Reassigning to systemd because the daemon runs by hand but not via 'systemctl start dhcpd.service'. Guys, any idea how to debug this ?

Please provide also the output of "systemctl list-jobs" while the start operation is stuck.

 JOB UNIT                                 TYPE  STATE
 153 systemd-readahead-done.timer         start waiting
  85 multi-user.target                    start waiting
 155 systemd-update-utmp-runlevel.service start waiting
 157 ntpd.service                         start waiting
 159 crond.service                        start waiting
 178 ntpdate.service                      start running
 179 time-sync.target                     start waiting
1237 dhcpd.service                        start waiting


Btw, is there any way to temporary enable debug log level on systemd w/o passing it via kernel parameter?

(In reply to Vlad from comment #9)
>  JOB UNIT                                 TYPE  STATE
>  153 systemd-readahead-done.timer         start waiting
>   85 multi-user.target                    start waiting
>  155 systemd-update-utmp-runlevel.service start waiting
>  157 ntpd.service                         start waiting
>  159 crond.service                        start waiting
>  178 ntpdate.service                      start running
>  179 time-sync.target                     start waiting
> 1237 dhcpd.service                        start waiting
OK, so things are pretty clear: ntpd.service is waiting for time-sync.target, which is waiting for ntpdate.service. (ntpd.service has After=time-sync.target). I think there's no bug here.
 
> Btw, is there any way to temporary enable debug log level on systemd w/o
> passing it via kernel parameter?
Either 'kill -SIGRTMIN+22 1' or 'systemd-analyze set-loglevel debug'.

okay, thanks. next thing, i guess, need to figure out why ntpdate is stuck