Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163284 - dhcpd doesn't load from init script, but loads from command line
Summary: dhcpd doesn't load from init script, but loads from command line
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcp
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-14 19:22 UTC by Gabriel Schulhof
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-27 19:58:31 UTC

Attachments (Terms of Use)

Description Gabriel Schulhof 2005-07-14 19:22:32 UTC
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:
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
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):

How reproducible:

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:


Comment 1 Jason Vas Dias 2005-07-14 20:14:41 UTC
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

Comment 2 Gabriel Schulhof 2005-07-14 22:42:01 UTC
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 !

Comment 3 Jason Vas Dias 2005-07-20 14:31:18 UTC
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 \

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

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.

Comment 4 Jason Vas Dias 2005-07-27 19:58:31 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.