Team, flameeyes has asked that we deprecate then eventually remove this option. He feels that too many init scripts are using it for no reason and it is making it very difficult to troubleshoot when daemons do not start successfully. My first step will be to remove the functionality but print a deprecation warning when someone uses the option, then at a later time we can go back with another bug and remove the option itself.
+1 I totally agree.
misuse in init.d scripts isn't a valid reason to drop an option from s-s-d. this would break compatibility with other systems shipping s-s-d, and break end users who want --quiet. plus, there are valid uses for this flag. there are daemons which crap all over stdout when starting up and that's just normal for them. the -q flag silences that.
What about reprecating it, but replacing it with a --silent option? The daemons crapping during normal start are a much lower proportion to those that actually print out during errors and are being shut up by --quiet right now.
(In reply to comment #3) > What about reprecating it, but replacing it with a --silent option? > > The daemons crapping during normal start are a much lower proportion to > those that actually print out during errors and are being shut up by --quiet > right now. This might work. What I think I could do is change -q/--quiet to just print a message that you should use --silent if this is what you really want. But, Mike does make a good point. Shouldn't we be filing bugs against all of our init scripts that use this flag and requesting that they drop it, or better yet, that they use OpenRC's default stop/start functions unless they have a good reason not to?
changing --quiet to --silent wouldn't address the compatibility issues (both with other distros and with user scripts) i'd rather file/fix bad init.d scripts. converting to default start/stop funcs would be even better.
Some of the converted scripts also use --quiet in their ssd options though :(
(In reply to comment #6) > Some of the converted scripts also use --quiet in their ssd options though :( Maybe we should file bugs and ask maintainers to refrain from doing this? I can see both sides of this. If a daemon is particularly verbose during startup, a maintainer may want to use it. However, they should be made aware that it can hide error messages a sysadmin may want to see.
I just had another thought. Sometimes, daemons themselves have quiet options that will skip all of the things they spit out on stdout but display error messages. IMO if that is the case, the maintainer should use the daemon's option instead of our --quiet option.
See commit 9afdf50667661812be936fe6d3b3a939b0c54061, stderr is no longer redirected through --quiet/-q. Anyway.. All affected init scripts need to be fixed. All the init scripts that I fixed in the past few years had -q/--quiet for *no* reason.
(In reply to comment #9) i think not swallowing stderr is probably OK for the majority of daemons i know --quiet is used with some to silence their spew because i've added it specifically for that purpose ;)
All, since we agreed that fixing the init scripts is the better way to go for this, I am closing this bug as worksforme. If someone disagrees, please feel free to reopen.
