On Fri, May 16, 2014 at 10:11:56AM +1000, Dave Chinner wrote:

On Fri, May 16, 2014 at 01:19:09AM +0200, Mateusz Guzik wrote:

quoted

Except there is no log entry if /var got frozen (and this is not an
imaginary example).

Freezing the filesystem that the freezing daemon logs to is, well, a
major application architecture fail. Sorry, catering for the lowest
common denominator (i.e. stupidity) is not an valid argument for
adding stuff to the kernel....

I'm only saying what you can encounter in varous companies. If aiding this
problem the way I proposed is not a good idea (and it turns out there is
a much better way), I'm not insisting.

quoted

Grabbig a debugger to inspect daemon's state is not
exactly what your typical support associate can or should do.

No, but they can read /proc/self/mountinfo, and grab sysrq-w output.
And they should be able to read that and tell that there is a freeze
hang from that info. This "filesystem hang triage 101" stuff....

quoted

But this was a side request, I'm not going to argue about including
this since turns out there is a better way.

Somewhere in the thread an idea to log long-standing freezes was
mentioned which would provide sufficient information as far as

You've already got the hung task timer firing when a fs is frozen
for too long. You'll see processes hung in sb_write_wait(), and that
tells you the filesystem is frozen. Then look at
/proc/self/mountinfo to find which fs is frozen....

But additional question was what initiated the freeze and it is not
answered by this. Hopefully a warning for long-standing freezes will be
implemented and that will answer the question.

Once more, I'm fine with mere 'frozen' in mountinfo, so I suggest we
drop this now side subject. If you really want to continue we can
discuss this in private. :->

-- 
Mateusz Guzik