Not all sysadmin tools should be silent by default

July 17, 2020

As a long term Unix person, I have wound up with a reflexive assumption that all of the programs and tools I write should be silent by default. This is the traditional Unix approach; Unix programs are supposed to be silent if all goes well and only print things if asked to or if something goes wrong, for good reasons. However, lately I've began thinking that this is not necessarily always correct and that under some circumstances my programs and tools should be somewhat verbose by default (with an option to make them Unix style silent).

A certain amount of the tools I write are normally run through automation (such as crontabs and scripts), where they can be supplied with whatever command line options we want, and they may or may not do something when run depending on the state of the system (or what they perceive that to be). If I'm running such a program interactively, it's generally an exceptional situation and I want and expect it to do something. If the program follows the Unix philosophy and is silent both when there is no work to be done and when there's work to do but it goes well, I'm at a loss for which one actually happened.

For this sort of program, I've come to believe that some verbosity by default is more helpful in practice. When I run the program interactively with no command line options, it will actually tell me what it did (or didn't do) and I won't be left wondering. When we run it through automation, we can give it the command line option that makes it more silent, so we don't get a barrage of emails from crontab or the like.

All of that sounds abstract, so let me make it concrete. One part of our ZFS spares system is a program called 'sanspares'. The primary job of sanspares is to either actually perform sparing or report on what sparing it would like to do, but it can run into various reasons it might not actually do any sparing despite wanting to. Right now, sanspares is a silent by default program, so if I run it interactively and it produces no output it could be for one of several reasons. If I'm checking what sanspares thinks about the health of a fileserver, the different reasons for not doing anything matter and I would like to know which one it was. I actually recently had to run sanspares interactively, and I had to do a bunch of fiddling with '-vv' flags until I was confident that I understood why it was doing what it was doing.

(Silence is especially not golden if there's a possibility that your program is actually broken. This was part of why I was running sanspares interactively, as I needed to fix an issue we'd found with it recently as well as understand the health of the fileserver.)

Comments on this page:

By jonys at 2020-07-18 02:17:09:

If the program follows the Unix philosophy and is silent both when there is no work to be done and when there's work to do but it goes well, I'm at a loss for which one actually happened.

I believe that's why make is verbose by default, and also why rm complains about nonexistent files unless you explicitly give it -f. It is certainly a good thing for programs with complex behaviors to say what they are doing.

By lousyd at 2020-07-18 15:14:52:

I have never understood silence to be a part of Unix philosophy. There are a lot of core tools that are not silent upon success. Sometimes I wish they were, in fact, but I remind myself that it's very easy to redirect (or at least filter) stdout.

Written on 17 July 2020.
« Malware spammers put .exe Windows executables in everything
Using Go build directives to optionally use new APIs in the standard library »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jul 17 22:00:14 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.