Bug#931867: /lib/init/init-d-script is sourcing /etc/default/* too late

2020-08-30 Thread Trek
On Thu, 11 Jul 2019 12:05:10 -0500
Justin Pasher  wrote:

> Moving it above the following block would ensure it's sourced first:

this is a chicken-egg problem: init-d-script sources /etc/default/$NAME
but $NAME is defined inside /etc/init.d/snmpd (that is $SCRIPTNAME)

init-d-script could be modified, for example to source at
first /etc/default/$(basename $SCRIPTNAME), but to retain backward
compatibility it should source also /etc/default/$NAME and it would
begin a sourcing mess with possible conflicts

i think the init-d-script sourcing feature is not really useful and the
right way to include variables it is to source the environment file
inside the /etc/init.d/snmpd script, like batmand does for example:

https://sources.debian.org/src/batmand/0.3.2-21/debian/batmand.init


another possible way it could be to define DAEMON_ARGS directly
inside /etc/default/snmpd, but I don't know how well it will play with
other init systems

ciao!



Bug#931867: /lib/init/init-d-script is sourcing /etc/default/* too late

2020-08-30 Thread Thorsten Glaser
On Sun, 30 Aug 2020, Trek wrote:

> this is a chicken-egg problem: init-d-script sources /etc/default/$NAME
> but $NAME is defined inside /etc/init.d/snmpd (that is $SCRIPTNAME)

It could do:

eval "$(grep '^NAME=' "$__init_d_script_name")"

This would cover most cases, and it could be made part of the API
of init-d-script that its users must have exactly one line matching
this which is a valid, context-free shell expression setting only $NAME.

Possible.

> init-d-script could be modified, for example to source at
> first /etc/default/$(basename $SCRIPTNAME), but to retain backward
> compatibility it should source also /etc/default/$NAME and it would
> begin a sourcing mess with possible conflicts

Erk. Also, they shan’t be sourced twice.

> i think the init-d-script sourcing feature is not really useful and the
> right way to include variables it is to source the environment file
> inside the /etc/init.d/snmpd script, like batmand does for example:
>
> https://sources.debian.org/src/batmand/0.3.2-21/debian/batmand.init

Yes, that too.

> another possible way it could be to define DAEMON_ARGS directly
> inside /etc/default/snmpd, but I don't know how well it will play with
> other init systems

That would only work in very simple cases.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"



Bug#931867: /lib/init/init-d-script is sourcing /etc/default/* too late

2019-07-11 Thread Justin Pasher

Package: sysvinit-utils
Version: 2.93-8

I started testing the upgrade from Debian Stretch to Buster, and I've 
encountered a problem that affects the snmpd package's init.d script. It 
looks like it has been changed to utilize /lib/init/init-d-script for 
its core functionality. However, by doing so, the SNMPDOPTS value is 
ignored from the init config file at /etc/default/snmpd. This is because 
of the following lines in /etc/init.d/snmpd:


==
DEFAULT_SNMPDOPTS="-Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I 
-smux,mteTrigger,mteTriggerConf"

[ -z "$SNMPDOPTS" ] && SNMPDOPTS=$DEFAULT_SNMPDOPTS
==

Because the /lib/init/init-d-script script sources /etc/init.d/snmpd 
BEFORE it sources /etc/default/snmpd, none of the values in 
/etc/default/snmpd are visible to /etc/init.d/snmpd. This results in 
SNMPDOPTS always being set to the default arguments.


One could view this as a bug in either snmpd or sysvinit-utils, 
depending on your viewpoint. However, it seems more appropriate for a 
fix to be applied to /lib/init/init-d-script within sysvinit-utils, as 
other scripts may try (or even be trying already) to use this method 
within the init.d script to set defaults. The /etc/init.d/snmpd script 
could manually force an inclusion of /etc/defaults/snmpd, but it seems a 
little redundant when /lib/init/init-d-script is supposed to do that work.


The line in question in /lib/init/init-d-script is below:

==
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
==

Moving it above the following block would ensure it's sourced first:

==
SCRIPTNAME="$__init_d_script_name"
scriptbasename="$(basename "$__init_d_script_name")"
if [ "$scriptbasename" != "init-d-script" ] ; then
    . "$__init_d_script_name"
else
    exit 0
fi
==

I checked the latest experimental version (2.95) and it doesn't have any 
changes like this (although it does fix the snmpd package install bug as 
referenced in #926390). Without knowing all the ins and outs of how 
/lib/init/init-d-script is used throughout Debian, I can't say if this 
change would be considered safe or not. Perhaps there are instances 
where the /etc/default/* config file tries to do more than just set some 
shell variables and it would cause some bizarre side effects.


Thanks.

--
Justin Pasher