Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 380073 - sys-apps/openrc: Warnings Can Be Suppressed with the EINFO_QUIET Environment Variable
Summary: sys-apps/openrc: Warnings Can Be Suppressed with the EINFO_QUIET Environment ...
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: OpenRC Team
Depends on:
Blocks: 374183
  Show dependency tree
Reported: 2011-08-21 14:28 UTC by Hanno Böck
Modified: 2012-11-30 22:53 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

fix-ewarn.patch (fix-ewarn.patch,646 bytes, text/plain)
2011-08-21 15:13 UTC, William Hubbs

Note You need to log in before you can comment on or make changes to this bug.
Description Hanno Böck gentoo-dev 2011-08-21 14:28:32 UTC
Just stumbled upon an issue: Latest openrc issues warnings if the parameter -c/--chuid is used. However, often noone will see those warnings, because --quiet suppresses them.

Just talked on irc with idl0r and we agreed that it's a bug in start-stop-daemon and it shouldn't suppress warnings on --quiet.
Comment 1 William Hubbs gentoo-dev 2011-08-21 14:41:18 UTC
Before I agree that this is a bug in s-s-d, I want to know how
baselayout-1 worked.

If this is different behavior than bl1, I can agree that this is a bug.
However, if the behavior is the same as bl1, then I would say that the
init scripts need to be fixed to not use --quiet.
Comment 2 William Hubbs gentoo-dev 2011-08-21 14:58:05 UTC

do you know if this was an intended change from baselayout-1?
Comment 3 William Hubbs gentoo-dev 2011-08-21 15:13:01 UTC
Created attachment 284113 [details]

If we want to go ahead with this change, this patch will take care of

This is not a bug in s-s-d, but possibly in libeinfo.

What does everyone else think? Should we add this?

Comment 4 SpanKY gentoo-dev 2011-08-21 15:50:21 UTC
i dont think it was intentional.  but i also dont think your patch is exactly how baselayout-1 did things.  in quiet mode, it would just dump the string ... it wouldnt include the colorized output and such.
Comment 5 William Hubbs gentoo-dev 2011-08-21 15:58:47 UTC

in that case, why would we want the output to be different in quiet mode
vs normal mode? A warning is a warning, so shouldn't we colorize it
regardless of whether we are in quiet mode?
Comment 6 William Hubbs gentoo-dev 2011-08-21 16:05:24 UTC

We actually have a setting, rc_nocolor, to control whether colorization
is used, so if we apply my patch, the user gets a say over whether the
colorization is used, which I think is probably a better choice than
forcing it one way or another just because --quiet is used.

What do you think?
Comment 7 William Hubbs gentoo-dev 2011-08-22 18:07:22 UTC
I have added this patch as commit 4ee62c7.
It will be part of the next release of openrc.
Comment 8 SpanKY gentoo-dev 2011-08-23 15:12:33 UTC
(In reply to comment #6)

i dont think you got my comment.  look at the baselayout-1 code:

ewarn() {
    if [[ ${RC_QUIET_STDOUT} == "yes" ]] ; then
        echo " $*"
        [[ ${RC_ENDCOL} != "yes" && ${LAST_E_CMD} == "ebegin" ]] && echo
        echo -e " ${WARN}*${NORMAL} ${RC_INDENTATION}$*"

it has nothing to do with color.  the colorization logic is handled by setting WARN/NORMAL/etc... to "", but the quiet logic is RC_QUIET_STDOUT.
Comment 9 William Hubbs gentoo-dev 2011-08-23 17:48:43 UTC
I did see that.

There is no RC_QUIET_STDOUT variable in openrc, but this is controled by
the is_quiet() function in libeinfo. Look at the einfo function in there
to see what I'm talking about.

I just took out the check for is_quiet() in ewarn because I can't think
of a situation where you would want warnings to be suppressed.
Comment 10 Maxim Kammerer 2012-11-26 20:40:22 UTC
Hi, so now there is no way to stop a daemon without printing a warning, if the daemon may have already (correctly) terminated by itself?
Comment 11 William Hubbs gentoo-dev 2012-11-30 22:53:25 UTC
(In reply to comment #10)
> Hi, so now there is no way to stop a daemon without printing a warning, if
> the daemon may have already (correctly) terminated by itself?

The request on this bug was to not suppress warnings, so that is how the code now works. All the -q command line option did was set the EINFO_QUIET environment variable.

Bug #439174 has been opened wrt this same issue, so please do not add more to this bug.