netifrc contains this line for clip (IP over ATM) start-stop-daemon --quiet --test --stop --pidfile /var/run/atmarpd.pid || return 1 Running it prints: * start-stop-daemon: fopen `/var/run/atmarpd.pid': No such file or directory At some point in the past, --quiet stopped being quiet for errors. Could you please add a --quieterror option that also silences errors (or modify --quiet to take an argument)? I'm going to work around it for now.
For reference, below are the hashes of the commits that made this change: 3cd293c515ddf44172ece36e785209084a11d3fc a06072b3959adc91ddf5157f69162977cbd48079 9afdf50667661812be936fe6d3b3a939b0c54061 I'm wondering if we should just suppress the error message when --test is on the command line?
I talked to idl0r about this, and the issue is that s-s-d --quiet was changed to not silence error messages, and reading a pid file that does not exist is considered an error. I believe that was done because service scripts are abusing --quiet in place of their downstream daemon's --quiet option or equivalent. My vote would be to undo this change, find service scripts abusing --quiet and fix them.
Can we clearly define for script consumers what a valid use of --quiet is then? I'm personally fine with --quiet=error, for scripts that really know what they are doing. --test is the is the best valid use I know.
It appears that discussion about the --quiet option has been going on for a while. Bug #380073 and bug #439174 are related.
After commits 72b58b, 5c3e5d and bb8a9c, OpenRC is in a consistent state with regard to --quiet. The --quiet switch is a global OpenRC switch that works by setting the EINFO_QUIET environment variable to yes. This has the affect of suppressing output from all einfo* and ewarn* calls, but not eerror* calls. In start-stop-daemon, we locally extend the behaviour of --quiet to suppress some eerror calls and to suppress stdout and stderr in the child process when we fork to start the daemon. Since we are suppressing some eerror* calls in s-s-d, should we make the eerror* suppression work the same way as ewarn* and einfo* suppression? Also, in start-stop-daemon, should we be suppressing the stdout and stderr of the child process, and by that path, the stdout and stderr of the daemon with the --quiet switch? Based on discussions on the previous bugs I have cited, the first answer seems to be yes, but I'm not sure about the second answer. Thoughts?
In commit a78b18e, I modified libeinfo so that eerror* calls are now silenced by the EINFO_QUIET variable being set to yes, like einfo* and ewarn* calls.
(In reply to Robin Johnson from comment #3) > Can we clearly define for script consumers what a valid use of --quiet is > then? > I'm personally fine with --quiet=error, for scripts that really know what > they are doing. > --test is the is the best valid use I know. +1 on that. William already reverted my commits. I think we shouldn't silence errors by default when passing --quiet. --quiet=error would be pretty handy though.
(In reply to Christian Ruppert (idl0r) from comment #7) > (In reply to Robin Johnson from comment #3) > > Can we clearly define for script consumers what a valid use of --quiet is > > then? > > I'm personally fine with --quiet=error, for scripts that really know what > > they are doing. > > --test is the is the best valid use I know. > > +1 on that. > > William already reverted my commits. I think we shouldn't silence errors by > default when passing --quiet. --quiet=error would be pretty handy though. I'm not opposed to what you had; I just want to make it be controlled a consistent way through all of OpenRC. Basically the way quiet works is it sets the EINFO_QUIET environment variable, which then controls whether einfo* and ewarn* calls in libeinfo output anything. Currently, in git, I have it set up so that eerror* calls check this variable as well. If we suppress errors with a separate option, I would rather it be done in a similar way to how --quiet suppresses einfos and ewarns, but with a separate env variable and maybe a separate command line switch.
Commit 2590bf7 moves eerror() suppression to a separate environment variable, EERROR_QUIET, which works exactly like EINFO_QUIET.
As of commit 445b297, the rc binary will set the environment variables EINFO_QUIET or EERROR_QUIET to control whether error messages are suppressed, based on command line options as follows: The -q/--quiet option, specified once, suppresses all einfo/ewarn output by setting the EINFO_QUIET environment variable to yes. Specifying it a second time also suppresses all eerror output by setting the EERROR_QUIET environment variable to yes. @idl0r: What do you think about reworking s-s-d some since the libeinfo library now knows by environment variables when to suppress messages? I would rather not test for quiet or verbose settings inside start-stop-daemon.c and just call the appropriate libeinfo functions.
Hi, I am reporting this here, because I think it is related to the changes introduced by this bug report. Today I updated openrc-9999 on my test system (so I guess my openrc version is now at commit 993e7d704404a8ff1a355bf4a38d1d92e7cc56cd (not sure how to verify)). I noticed the following on boot (from rc.log): * Starting rsyslogd ... * start-stop-daemon: fopen `/var/run/rsyslogd.pid': No such file or directory [ ok ] * Starting ntpd ... * start-stop-daemon: fopen `/var/run/ntpd.pid': No such file or directory [ ok ] * Starting sshd ... * start-stop-daemon: fopen `/var/run/sshd.pid': No such file or directory [ ok ] Do these init.d scripts need an update, because they use the "--quiet" parameter? I don't expect that, because as far as I understand it should be normal that there isn't a pidfile yet.. so I don't understand why start-stop-daemon is complaining about a missing pidfile.
(In reply to Thomas D. from comment #11) > Hi, > > I am reporting this here, because I think it is related to the changes > introduced by this bug report. > > Today I updated openrc-9999 on my test system (so I guess my openrc version > is now at commit 993e7d704404a8ff1a355bf4a38d1d92e7cc56cd (not sure how to > verify)). > > I noticed the following on boot (from rc.log): > > * Starting rsyslogd ... > * start-stop-daemon: fopen `/var/run/rsyslogd.pid': No such file or > directory > [ ok ] > * Starting ntpd ... > * start-stop-daemon: fopen `/var/run/ntpd.pid': No such file or directory > [ ok ] > * Starting sshd ... > * start-stop-daemon: fopen `/var/run/sshd.pid': No such file or directory > [ ok ] > > Do these init.d scripts need an update, because they use the "--quiet" > parameter? I don't expect that, because as far as I understand it should be > normal that there isn't a pidfile yet.. so I don't understand why > start-stop-daemon is complaining about a missing pidfile. No, I know about these extra messages. there is nothing wrong with the init scripts. I have another change I am having someone on the team take a look at that is going to hide these messages unless you specifically want to see them.
This was fixed in OpenRC-0.12.2 and will be included in OpenRC-0.13 as well.
You should repeat the quiet option to suppress the error output, e.g. -q -q, -qq, --quiet --quiet.
