From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-2 Description of problem: /etc/rc.d/init.d/dhcpd says failed, and a subsequent ps ax | grep dhcp does indeed fail to show dhcpd. The syslog says the following: Jul 14 15:06:10 achilles dhcpd: Can't open lease database /var/lib/dhcp/dhcpd.leases: Permission denied -- Jul 14 15:06:10 achilles dhcpd: check for failed database rewrite attempt! Yet, when, as root, I run dhcpd eth1 it works fine - that is, it starts, gives me some nice messages as to what it's doing, forks into the background and starts serving up IPs like a good little daemon. Thus, I conclude that I did not botch up its configuration file and the problem lies elsewhere. My /etc/sysconfig/dhcpd contains DHCPDARGS=eth1 so that's not the problem. I suspect it's an SElinux issue (that is, the dhcpd's context when run from an init script differs from its context when run from the command line), however, there are no selinux messages in the syslog. In fact, I have no SElinux "denied" messages of any kind in my syslog. Version-Release number of selected component (if applicable): dhcp-3.0.2-14.FC4 How reproducible: Always Steps to Reproduce: 1. Install dhcp 2. After properly configuring it and adding it to the appropriate runlevels (I like chkconfig --level 345 dhcpd on), try starting it from the init script: /etc/rc.d/init.d/dhcpd start 3. Watch it fail. 4. Run dhcpd eth1 from the command line. 5. Watch it succeed 6. Scratch your head as to why it fails from the init script, but not from the command line. Actual Results: I scratched my head as to why it failed from the init script and not from the command line. Expected Results: dhcpd should start equally successfully from an init script as from the command line. Additional info: None.
Yes, this is probably to do with SELinux. SELinux audit messages are now logged to /var/log/audit/audit.log. Try: # audit2allow < /var/log/audit/audit.log Please append the output to this bug. Does "service dhcpd start" work after you do "setenforce 0" ? I definitely cannot reproduce this problem here on a machine with SELinux enabled.
Possible workaround: setenforce 0 service dhcpd start service dhcpd stop setenforce 1 service dhcpd start Very strange. Once I ran it with no enforcement, it works with enforcement as well, even across reboots. Off-topic: Wow ! audit2allow is really, really, really cool !
I cannot reproduce this problem . If dhcpd is run without a /var/lib/dhcp/dhcpd.leases file, then it exits with an error. So the dhcpd initscript does: " if [ ! -f /var/lib/dhcp/dhcpd.leases ] ; then touch /var/lib/dhcp/dhcpd.leases [ -x /sbin/restorecon ] && [ -d /selinux ] && /sbin/restorecon \ /var/lib/dhcp/dhcpd.leases fi " If the /var/lib/dhcp/dhcpd.leases file exists when dhcpd starts up, the first thing it does is to read and then rewrite it - and when dhcpd creates this file, it has the correct SELinux file context. It could be that there is something with the SELinux policy after a clean-install of FC-4 that stops the restorecon working when run from an initscript. What version of SELinux are you using ? Did you get any output from the audit2allow command in my previous comment ? If so, please append it to this bug.
I cannot reproduce this problem and the further information requested was not supplied, so this bug is being closed as 'NOTABUG'. If you can still reproduce this bug, please supply the information requested in the previous comment and re-open this bug - thanks.