dhcpcd: start-up scripts

From: Markus Mayer <[email protected]>

Add System V start-up script for dhcpcd that is run after the network has been brought up.

Signed-off-by Markus Mayer <[email protected]>

From: Markus Mayer <[email protected]>

Add systemd start-up configuration for dhcpcd that is executed after the network has been brought up.

Signed-off-by Markus Mayer <[email protected]>

---
 package/dhcpcd/dhcpcd.mk      |  8 ++++++++
 package/dhcpcd/dhcpcd.service | 13 +++++++++++++
 2 files changed, 21 insertions(+)
 create mode 100644 package/dhcpcd/dhcpcd.service

Quoted 6 lines

From: Markus Mayer <[email protected]>

Add System V start-up script for dhcpcd that is run after the network has been brought up.

Signed-off-by Markus Mayer <[email protected]>

I've applied, just two comments.

package/dhcpcd/S41dhcpcd line 11

Quoted 6 lines

package/dhcpcd/S41dhcpcd new file +6 -0

+DAEMON=/sbin/dhcpcd
+CONFIG=/etc/dhcpcd.conf
+PIDFILE=/var/run/dhcpcd.pid
+
+[ -x $DAEMON ] || exit 0
+[ -f $CONFIG ] || exit 0

We have these in a lot of init scripts, so I kept them. But I find those tests pretty silly in fact:

- The daemon should definitely be there, as it's installed by the same package. And if it turns out not to be there, I'd prefer a loud failure than an init script that silently ignores the problem.

- Same for the configuration file: I prefer a loud error than an init script that ignores the problem.

Yann, Peter, Arnout, can we agree that such tests should be removed entirely, and we let the init script fail if the daemon does not exist, and the daemon fail if its configuration file does not exist ?

Quoted 2 lines

- Same for the configuration file: I prefer a loud error than an init script that ignores the problem.

Agreed, too.

However:

- if the config file is mandatory, then this should be a failure.

- if the config file is optional, then it missing should be silently ignored and the service started nonetheless.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> writes:

Quoted 2 lines

+[ -x $DAEMON ] || exit 0
+[ -f $CONFIG ] || exit 0

We have these in a lot of init scripts, so I kept them. But I find those tests pretty silly in fact:

- The daemon should definitely be there, as it's installed by the same package. And if it turns out not to be there, I'd prefer a loud failure than an init script that silently ignores the problem.

- Same for the configuration file: I prefer a loud error than an init script that ignores the problem.

Yann, Peter, Arnout, can we agree that such tests should be removed entirely, and we let the init script fail if the daemon does not exist, and the daemon fail if its configuration file does not exist ?

Quoted 9 lines

Quoted 2 lines

- Same for the configuration file: I prefer a loud error than an init script that ignores the problem.

Agreed, too.

However:

- if the config file is mandatory, then this should be a failure.

Quoted 2 lines

- if the config file is optional, then it missing should be silently ignored and the service started nonetheless.

So you want explicitly handling for the "missing configuration file" situation in the init script?

I wanted to avoid explicit handling, and just let the daemon whine (or not) if its config file is missing.

Quoted 5 lines

So you want explicitly handling for the "missing configuration file" situation in the init script?

I wanted to avoid explicit handling, and just let the daemon whine (or not) if its config file is missing.

The idea is that the script contains sensible defaults, but scans an optional file (e.g. /etc/default.d/my-daemon.conf) that a user can provide to override the defaults.

IIRC, that's what was discussed and concluded a while ago (2 years?).

I would like that users can change the behaviour of a service without having to sed/replace the init script.

Quoted 7 lines

Quoted 6 lines

So you want explicitly handling for the "missing configuration file" situation in the init script?

I wanted to avoid explicit handling, and just let the daemon whine (or not) if its config file is missing.

Quoted 8 lines

The idea is that the script contains sensible defaults, but scans an optional file (e.g. /etc/default.d/my-daemon.conf) that a user can provide to override the defaults.

IIRC, that's what was discussed and concluded a while ago (2 years?).

I would like that users can change the behaviour of a service without having to sed/replace the init script.

I think we're not talking about the same thing. I'm not talking about /etc/default/foobar containing additional shell variables to tweak the init script behavior.

I'm talking about the configuration file read by the daemon itself (/etc/lighttpd/lighttpd.conf for example).

Hello,

Quoted 9 lines · Yann E. MORIN

Quoted 2 lines

- Same for the configuration file: I prefer a loud error than an init script that ignores the problem.

Agreed, too.

However:

- if the config file is mandatory, then this should be a failure.

Quoted 2 lines

- if the config file is optional, then it missing should be silently ignored and the service started nonetheless.

So you want explicitly handling for the "missing configuration file" situation in the init script?

I wanted to avoid explicit handling, and just let the daemon whine (or not) if its config file is missing.

I vaguely remember a recently added package where the daemon would silently
fail to start if the config file is missing, and which doesn't even have a default config file. So I think checking for existence of the config file in the init script (if the config file is mandatory) makes sense.

Hello,

Quoted 4 lines · Arnout Vandecappelle

I vaguely remember a recently added package where the daemon would silently
fail to start if the config file is missing, and which doesn't even have a default config file. So I think checking for existence of the config file in the init script (if the config file is mandatory) makes sense.

So I suppose your suggestion is that the init script should abort with a failure if the configuration file doesn't exist. Correct?

Exactly. "Failure" anyway just means an error message on the console, not that
the system fails to boot.

Quoted 19 lines

Hello,

Quoted 11 lines · Yann E. MORIN

Quoted 2 lines

- Same for the configuration file: I prefer a loud error than an init script that ignores the problem.

Agreed, too.

However:

- if the config file is mandatory, then this should be a failure.

- if the config file is optional, then it missing should be silently ignored and the service started nonetheless.

So you want explicitly handling for the "missing configuration file" situation in the init script?

Quoted 2 lines

I wanted to avoid explicit handling, and just let the daemon whine (or not) if its config file is missing.

I vaguely remember a recently added package where the daemon would silently
fail to start if the config file is missing, and which doesn't even have a default config file. So I think checking for existence of the config file in the init script (if the config file is mandatory) makes sense.

Regards,
Arnout

Signature · 10 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 2 lines

Exactly. "Failure" anyway just means an error message on the console, not that
the system fails to boot.

Sure, but some scripts currently just "exit 0" with no error message whatsoever when the configuration file is missing.

So, let's summarize our policy:

* Never check if the daemon executable is present, because that's silly, Buildroot guarantees it's there.

* If the daemon needs a configuration file, always check if it exists, and if not, bail out with an error message.

But... wait, if Buildroot guarantees that it installs a configuration file for this daemon, having the init script check its presence is pretty much as silly as checking the presence of the daemon executable itself.

So?

Arnout, All,

On 2017-11-04 20:56 +0100, Arnout Vandecappelle spake thusly:

Quoted 23 lines · Thomas Petazzoni

Quoted 21 lines

Hello,

Quoted 11 lines · Yann E. MORIN

Quoted 2 lines

- Same for the configuration file: I prefer a loud error than an init script that ignores the problem.

Agreed, too.

However:

- if the config file is mandatory, then this should be a failure.

- if the config file is optional, then it missing should be silently ignored and the service started nonetheless.

So you want explicitly handling for the "missing configuration file" situation in the init script?

I wanted to avoid explicit handling, and just let the daemon whine (or not) if its config file is missing.

Quoted 4 lines

I vaguely remember a recently added package where the daemon would silently
fail to start if the config file is missing, and which doesn't even have a default config file. So I think checking for existence of the config file in the init script (if the config file is mandatory) makes sense.

Then it is the responsibility of the package.mk to install one if it is mandatory. Otherwise,that means the packaging is incomplete because it does not allow the package to work as expected.

And in that case, I side with Thomas' initial suggestion: we should not check from the init scripts, because we expect the .mk files to be correct.

Regards,
Yann E. MORIN.

Quoted 15 lines

Regards,
Arnout

Signature · 10 lines

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 3 lines

Then it is the responsibility of the package.mk to install one if it is mandatory. Otherwise,that means the packaging is incomplete because it does not allow the package to work as expected.

So you mean all packages should do like inadyn: install an example
configuration file even if that is guaranteed not to work.

Quoted 3 lines

Then it is the responsibility of the package.mk to install one if it is mandatory. Otherwise,that means the packaging is incomplete because it does not allow the package to work as expected.

So you mean all packages should do like inadyn: install an example
configuration file even if that is guaranteed not to work.