[arch-general] Init script hidden output (careless /dev/null redirection)
Hi. A recurring source of frustration for my use of Arch Linux is that many init scripts fail to produce any output, to either the console or syslog, when something goes wrong and the script fails. The particular cause is always case-dependent (usually stemming from some config error). Some underlying programs produce no output; I'm not proposing that Arch address all such cases. Instead, the scenario I continue to run into is that the init script redirects all output, good or bad, to /dev/null. In my opinion, this is excessively heavy-handed and obscures the behavior of the system only to make debugging difficult. I also interpret this behavior to be in contrast to the Arch Way document, particularly in that it does not satisfy: "Arch Linux developers and users believe that trying to hide the complexities of a system actually results in an even more complex system, and is therefore to be avoided." I have posted bug reports about some packages (e.g., https://bugs.archlinux.org/task/29769), some of which have resulted in more favorable output. However, the issue is more general, and I'm unsure whether I should continue posting such bugs. So, can anyone clarify whether there is some existing policy about this behavior? I first assumed this was a matter of limited manpower, but discussion in that backuppc bug, in particular, leads me to suspect that others in the project don't have my convictions. Thanks. ~Jacob
On Thu, Sep 13, 2012 at 9:58 PM, Jacob Joseph <jacob@jjoseph.org> wrote:
Some underlying programs produce no output; I'm not proposing that Arch address all such cases. Instead, the scenario I continue to run into is that the init script redirects all output, good or bad, to /dev/null. In my opinion, this is excessively heavy-handed and obscures the behavior of the system only to make debugging difficult. Systemd will offer you a solution. Nothing is printed during boot and everything is logged.
I have posted bug reports about some packages (e.g., https://bugs.archlinux.org/task/29769), some of which have resulted in more favorable output. I fixed your bug report as _you_ wished. How the output can be more favorable? I only asked you some help to fix the issue behind this hiding and you just don't care.
However, the issue is more general, and I'm unsure whether I should continue posting such bugs. Systemd will probably remove all this *bad* but convenient hiding. I reminds you, this is to have a clean boot when everything goes fine.
So, can anyone clarify whether there is some existing policy about this behavior? I first assumed this was a matter of limited manpower, but discussion in that backuppc bug, in particular, leads me to suspect that others in the project don't have my convictions. Everyone doesn't think like you? Weird! For my part I do not have a definite opinion on the matter.
-- Sébastien "Seblu" Luttringer www.seblu.net
On Fri, 14 Sep 2012 00:10:54 +0200 Sébastien Luttringer <seblu@seblu.net> wrote:
However, the issue is more general, and I'm unsure whether I should continue posting such bugs. Systemd will probably remove all this *bad* but convenient hiding. I reminds you, this is to have a clean boot when everything goes fine.
Sébastien, I think this comment gets directly at any misunderstanding I may have. Personally, I don't care how much output happens or whether there is any at all when things work, since I don't need to read it. However, I most certainly do want to be able to read information about what doesn't work. My interest in Arch Linux is the promise of making the system easy to use, *and* fix, without obscuring or obfuscating the necessary detail. I'm happy to file bugs and patches for all of the other init scripts that strike me. Those for mpd and apache caught me just the other day. Do others have any thoughts on this matter? ~Jacob
Do others have any thoughts on this matter?
I like to know whats going on. Output in some form is always welcome, although errors should stand out and be obvious. -- Yesterday is history. Tomorrow is a mystery. Today is a gift. That's why its called the present. Headmaster Squall :: The Wired/Section-9 Close the world txen eht nepo $3R14L 3XP3R1M3NT$ #L41N http://twitter.com/headmastersqual
Do others have any thoughts on this matter?
Rather than null, why not just send to an empty tty which a user can optionally switch to. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
participants (4)
-
Jacob Joseph
-
Kevin Chadwick
-
Squall Lionheart
-
Sébastien Luttringer