Bug 163284 - dhcpd doesn't load from init script, but loads from command line
dhcpd doesn't load from init script, but loads from command line
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-14 15:22 EDT by Gabriel Schulhof
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-07-27 15:58:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gabriel Schulhof 2005-07-14 15:22:32 EDT
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.
Comment 1 Jason Vas Dias 2005-07-14 16:14:41 EDT
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.
Comment 2 Gabriel Schulhof 2005-07-14 18:42:01 EDT
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 10:31:18 EDT
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.


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