I find there are times (many times) when the hard-coded --quiet switch to runscript.sh makes debugging initscripts much harder than necessary. I either remove --quiet from the initscript or edit /sbin/runscript.sh to disable --quiet altogether. Both cause problems when updating world. It seems that it would be easy to add a runscript configuration file in /etc/conf.d. This is appropriate because /etc/conf.d has file setting startup options for initscripts, and runscript is part of every Gentoo initscript I've seen. I don't know what options would be exposed, but I'm hoping for one in particular: FORCE_RC_QUIET_STDOUT="no" (or "yes", if the person always wants --quiet behavior). runscript.sh would need to source /etc/conf.d/runscript, and lines 442-444 might change to: --quiet) RC_QUIET_STDOUT="yes" if [ -z "FORCE_RC_QUIET_STDOUT" ]; then RC_QUIET_STDOUT="$FORCE_RC_QUIET_STDOUT" fi ;; Of course, there are many other ways to handle this, such as not parsing --quiet if FORCE is set and RC_QUIET_STDOUT was initialized to the FORCEd value. Hopefully I am not the only Gentoo user that prefers full disclosure from their operating system, as opposed to hiding kernel and other startup messages behind cute pictures of Tux (he's on my credit card, I don't need a boot splash) or surpressing them completely. If I *am* the only Gentoo user that wants to control --quiet, then probably this request should be ignored. =-) Reproducible: Always Steps to Reproduce: 1. 2. 3.
Whoops, my example script should have used [ -n "$..." ] instead of [ -z "$..." ]. I think I need a preview button on bugzilla.
what hardcoded --quiet ? i dont see any such beast in baselayout ...
I apologize for my lack of clarity. The initscripts that hardcode --quiet when calling start-stop-daemon (also in baselayout). I guess I was under the (probably wrong) impression that runscript.sh had something to do with it because it interprets the initscripts. So I still think that baselayout is the right place to make my suggested change, if it belongs anywhere. Certainly we should *not* handle this uniform task (enabling/disabling) individually in every initscript.
in other words, you want us to patch start-stop-daemon.c to ignore the --quiet optoin if an env var is set ?
I suppose it has to be an environment variable, unless we create a start-stop-daemon config file. Which might not be a bad idea.
I can see where this might be useful. I've had more than one instance where a daemon (usually sshd) doesn't want to start up (prints [!!] as its status), and I'm left a bit puzzled as to the reason why, so I had to edit the initscript to remove the --quiet param so I could get an idea of what was h0rking it.
weeeeeeeeell i fixed the sshd init script to just run `sshd` since the usage of start-stop-daemon with ssh was pointless :)
A fine point about sshd. That said, I want to mention that I would still like this feature for many other initscripts. Would this feature be trivial to add?
I just had a look at start-stop-daemon.c. It seems that there may be other parameters besides --quiet (or --verbose) that a person might want to override. For overriding command-line values, I would think that you would call an env var checking function just after parse_options() is called from main(). If you wanted to be able to change the default value of an option, you could call the same or a similar function before parse_options(). Since there's no options struct, everything is global (was this translated straight from Debian's perl version?). This means that set_default_options() and override_options() functions don't even need to take parameters. Normal unix-ish behavior is to have command-line options override env vars, yes? So we might want to choose an env var name that makes it clear we are overriding command-line values. Some ideas might be SSD_FORCE_QUIETMODE, SSD_ALWAYS_QUIETMODE, or SSD_OVERRIDE_QUIETMODE . You could also have SSD_DEFAULT_QUIETMODE, etc. A single env var parser parse_env_options(int default) would grab all vars with SSD_, then check the second token for default or override (whatever), and then set the global variable. If default != 0, then it would only read things with DEFAULT for the second token. Just an idea. Those env var names I made up were pretty long; maybe there's good and short names we can come up with.
baselayout-1.12.0-alpha2 has a working /lib/rcscripts/rc-daemon.sh which acts as a wrapper to start-stop-daemon. It could easily be accomodated to filter/add flags to the s-s-d calls RC_SSD_MESSAGES="verbose|quiet" As the two are mutually exclusive the following actions would be taken RC_SSD_MESSAGES="" - let the init script work as normal RC_SSD_MESSAGES="verbose" - add the verbose flag if not present and remove the quiet flag if present RC_SSD_MESSAGES="quiet" - add the quiet flag if not present and remove the verbose flag if present Another alternative would be to use the existing RC_QUIET_STDOUT and RC_VERBOSE vars in /sbin/functions.sh - although I would be in favour of renaming RC_QUIET_STDOUT to just RC_QUIET in this case.
After much thought, I believe that this should be implemented on a per init script basis as most init script authors are using --quiet when there really is no need for it. Infact, most daemons have switches to disable chatter which should be used instead. I'm going to close WONTFIX. If you want this, then please open bugs for the packages where you would like this removed from.
