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

[Steve Litt]

On Wed, 19 Sep 2012 08:03:53 -0400, Thomas Gardner said:
> On 9/19/12, Joseph Mack NA3T <jmack at wm7d.net> wrote:
> > [...]
> > again you're just saying loudly to the world that you accept
> > that the utilities (in this case df) don't work.
> 
> Cut me some slack, I said I'd try to get around to it.  Don't know if
> it'll be accepted or not, but I said I'd at least try.  Besides, in
> the case of df, someone DID fix it (-P), and folks are STILL
> complaining about it.

I like long threads when they're informative, but from my viewpoint this
thread is a troll. A very courteous troll, but a troll just the same.

It starts out with a question about fsck, and in my opinion a
premature question. The way my mama taught me is:

1) RTFM (or STFW)
2) Experiment
3) Ask on your LUG list

My mama taught me that if you ask on your LUG list, you really listen
to the answers you receive, and redo steps 1 and 2 before asking
further questions. That's not what happened in this thread.

Then, apropos to nothing, after a solution was found (and by the way,
there was no post saying <SOLVED> in the subject so others could
benefit), the original poster morphs the thread into a whine
about Unix/GNU utilities such as pf not being machine-readable enough.
Gimme a break, that's what Perl is for. Or awk. Or cut.

The df program has stood the test of time as a workhorse that does what
almost everyone needs from it. If one needs something special from it,
instead of griping about it, why not write an interface to get the info
out of it in the format one desires?

And then there's this. On my Ubuntu 11.10 system, df with no args
inserts no carriage returns on any reasonable length path.

slitt at mydesk:~$ df | grep flamingo | wc -l
1
slitt at mydesk:~$ df | grep flamingo
/dev/sda3             14397068   5732332   8357576
41% /mnt/antidisestablishmentarianism/flamingodancing/alexanderthegreat/
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
slitt at mydesk:~$ 

I'm assuming here that the original poster didn't mistake his
terminal's wrapping, which would not put a <cr>
into into df's stdout, for an actual <cr> in df's stdout. Piping it
into wc would prove the point one way or the other.

Even if somehow pf DID insert <cr> into its stdout, the following
choices are available:

A) Just once, write a Perl or awk filter to detect which lines are
continuations, using regex, and join split lines. Spend a half hour
writing the program, use it forever.

B) Find the necessary information in the /proc system (I could find no
obvious way of doing this)

C) On a non-essential machine, download coreutils source, copy df.c to
dfm.c, change all instances of LONGEST_HUMAN_READABLE to
LONGEST_HUMAN_READABLE2, and #define LONGEST_HUMAN_READABLE2 as 10,000
or whatever guarantees it won't go over. I didn't try this, but I'm
pretty sure it will work. If it's compiled static, it should be useful
on any machine.

D) Read this:
http://askubuntu.com/questions/55702/df-h-command-puts-line-breaks-in-output-how-do-i-fix

Normally I'd just filter out this one guy with a repeated tendency to
ask before researching, immediately re-ask, post ambiguous symptom
descriptions, and just basically churns the list. But that doesn't
screen out the voluminous multitude of responses. My suggestion would be
not to respond to a person whom you know darn well has the technical
chops to fix the problem with minimal help from the list but chooses
not to, repeatedly shoots from the hip with questions, immediately
re-asks, and just generally churns the list. Look back in the archives
-- this has been going on a long time, it's not just this thread.

Once such a poster gets no response, he'll undoubtedly research and
experiment before asking, and the whole list will be better off for it.

Thanks

SteveT

Steve Litt                *  http://www.troubleshooters.com/
                          *  http://twitter.com/stevelitt
Troubleshooting Training  *  Human Performance