[TriLUG] e2fsck under cron gets retcode=8 operational error

[Aaron Schrab]

At 08:34 -0700 19 Sep 2012, Joseph Mack NA3T <jmack at wm7d.net> wrote:
>On Wed, 19 Sep 2012, Aaron Schrab wrote:
>
>>At 05:37 -0700 19 Sep 2012, Joseph Mack NA3T <jmack at wm7d.net> wrote:
>>>o output should be machine readable
>>
>>At least with df, there is an option for that.  I disagree that that 
>>should be the default.  Far more people will be looking at the df 
>>output themselves than will be writing code to parse it;
>
>this is the problem. It depends whether you think
>
>o computers should require humans as I/O devices in order to maintain 
>the machine.
>
>o should run unattended, maintaining themselves and each other for 
>their lifetimes and only calling for attention on a failure beyond 
>their control (eg disk needs to be physically replaced).
>
>I subscribe to the 2nd view. In this case, anyone running `df` is 
>doing so for their own interest, not to run the machine. The output of 
>df should be optimised for a computer, not for a human, which has much 

Computers are there to serve people, as such I believe that they should 
be optimized for people.  There's nothing wrong with people running df 
for their own interests.  A large portion of people maintaining Linux 
machines only have a small number of them, in which case it's likely 
that they'd spend more time trying to automate these types of tasks than 
any automation could ever save.

>You have to know that the option is there in the first place and you 
>have to know that the utility was written for humans, not for 
>computers. You have to remember -P every time you use df not just 
>once.

You don't need to know that the option is there.  You just need to read 
the docs, which is something that should be done before scripting some 
command regardless of this type of issue.  I'll concede that if you're 
calling the utility from multiple places you'd need to remember it each 
time, but that will still be less often than it will be needed in 
interactive use.

>>>o make best effort. If you don't have a tty, then do the things 
>>>you can do without a tty.
>>
>>Doing this would result in a program that requires a tty in some 
>>cases, but not others.  It may work without a tty in most cases, but 
>>require one when something unusual happens.  That would make it more 
>>likely that a script using that tool would be deployed before the 
>>problem is found.  With the tty always being required, the problem 
>>should be found early in development.
>
>but I don't have a tty. e2fsck can work without one and if it can work 
>without a tty, then it should. It shouldn't fail because it doesn't 
>have a tty, that wasn't even needed for the job it was asked to do.

So fsck can work fine without a tty when fsck wasn't actually necessary, 
and some other situations.  In your case you're fine with that 
limitation, but other people writing scripts may not be.  I still say 
that it's better for it to fail early and consistently than it would be 
for it to work in some cases but not others.  Especially since there are 
options it can be given to have it work properly without a tty.  If it 
had given a useful error message you likely would have found the 
necessary option in a few minutes after your first attempt failed, and 
that would suit both your use and people who have stricter requirements.

>>>If an unknown option is given, ignore it, with a warning.
>>
>>Definitely not.  Warnings are too likely to be ignored.
>
>If you ignore warnings, you have been warned and you can't say 
>otherwise.

Depending on what the command is doing, by the time somebody can react 
to the warning it may already be too late.

>When I said that unknown options should be ignored, I was thinking of 
>the scripts that maintain my machines, that no longer work properly, 
>because of upgrades in utilities that are broken by design.

Scripts are even less likely to notice that some unrecognized option was 
ignored.  Having that happen would reduce portability of scripts, not 
increase it.  If the option wasn't necessary for the script to work 
properly, why was it there in the first place?  My example with rm was, 
admittedly, an extreme case but there's truly no way for a command to 
know if some unrecognized option is critical or merely something that 
would provide a minor enhancement.  The safest thing that the command 
can do is to fail in that case.  It will be easier to fix a script that 
fails where such a problem occurs than if the script continues on in a 
subtly broken way.

>Recently I found that the new version of `find` gives sheets of 
>warnings when running with a script I've been using for a decade. It 
>says I have the options in the wrong order. Well tough. I have a life 
>to get on with.  I'm not going to spend my life mopping up after people 
>who decide to rewrite something that worked for a decade, so that it's 
>cast as an error on my part.

I'm assuming you're talking about the "find: paths must precede 
expression" warning, although I get only two lines of output for that 
not sheets.  Your usage was always incorrect, but it happened to be 
accepted by some versions of find.  Warning about the incorrect usage 
makes it more likely that scripts will be written in a portable way.  
That warning can also point out actual errors.  If you run `find . -name 
*.c`, without quoting the asterisk your shell may expand that to 
multiple file names resulting in that warning, which in that case would 
be pointing to a real problem.