Bug 3601 - DHCPD S80dhcp-server startup script issues
Summary: DHCPD S80dhcp-server startup script issues
Status: RESOLVED FIXED
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: PC Linux
: P5 minor
Target Milestone: ---
Assignee: Gustavo Zacarias
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-13 14:19 UTC by Dmitry K
Modified: 2013-11-18 10:40 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry K 2011-04-13 14:19:00 UTC
1. DHCPD is currently unusable by default due to line 15 in S80dhcp-server script which is unconditional 'exit 1'.

2. DHCPD is always started. There are no means to disable dhcpd startup on boot.
I suggest to rename S80dhcp-server to dhcp-server and use S* symlink when needed.

3. Improper check in line 19:
test -f /usr/sbin/dhcpd || exit 0
I suggest to use execute permission check:
test -x /usr/sbin/dhcpd || exit 0
Comment 1 Thomas Petazzoni 2013-11-14 00:16:38 UTC
I think point (1) is intentional: make sure the script doesn't do anything until there is a proper configuration.

(2) is expected: all the init scripts in Buildroot work like this.

(3) is really cosmetic I believe.

Gustavo, what do you think? Can you have a look at the remaining issues, if any, and make a final call about this bug?
Comment 2 Gustavo Zacarias 2013-11-14 12:07:18 UTC
1) That check can be removed, dhcpd won't start without a valid /etc/dhcpd.conf (there's nothing copied there by the package).

2) Expected behaviour as Thomas said, the shipped initscripts are for normal/simple usage scenarios, you can remove shipped initscripts via a custom packaging script (like i do) and use your own (ditto, for example with a config subsystem built into them).

3) The package installs the file with the proper permissions, if it's -x it won't be executable anyway, i agree with Thomas. If there were a file that matches and isn't +x it would be some user inflicted problem.

I'm sending a patch that revamps the initscripts to the mailing list with some extra sanity checks.
Comment 3 Peter Korsgaard 2013-11-18 10:40:59 UTC
Fixed in git (dcefce4cf81) by Gustavoz, thanks