Not all sysadmin tools should be silent by default
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
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:Written on 17 July 2020.