Bug#931867: /lib/init/init-d-script is sourcing /etc/default/* too late
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
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
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