[arch-general] Troubleshooting random crash

[Gaetan Bisson]

[2013-02-06 19:06:45 -0500] Andre Goree:
> Not really too keen on downgrading a bunch of packages that might break
> dependencies and provide a REAL mess.  If I have to go through that long
> process, I'd rather just reinstall -- which at this point I'm planning
> to do anyways.

Well, there is little point in posting to this list if you have no
motivation to actually investigate the problem.

For starters, you've upgraded Linux from 3.6.11 to 3.7.4 in the window
when you report the issue appeared; from the symptoms you described,
it's a likely suspect. Downgrading it is far from being a "REAL mess":
you only need to downgrade/rebuild the external modules you really need
(probably none).

> In fact it seems
> all system processes hang because no logs are produced after the issue
> rears it's ugly head.

Ah. So that would mean your issue is I/O related, then?

> > So you produce nothing at work?
> 
> Not sure if you're just being an ass or not, however if you aren't:
> that has nothing at all to do with the issue and I merely wanted to
> establish _why_ I was using btrfs on a machine that I have running at my
> job -- which is _also_ inconsequential in the context of my email.  If
> you indeed were being an ass, congrats, you succeeded.

Once you were done being offended, you could have looked for the meaning
behind the words I used: that your "main work desktop" really qualifies
as "a production server".

But, of course, as you have so unequivocally declared, btrfs has
absolutely "nothing at all to do with the issue". And your statement
above implying that the problem is I/O related is just a coincidence.

Reporting issues is worthless when speculation is substituted for hard
data. For example, a good report would have gone: "I believe this issue
is unrelated to btrfs being my root filesystem since, on another Arch
machine running ext3, I observe the following identical symptoms: first,
`ssh -vvv` hangs at exactly the same point; second..."

> > How about looking at the system logs to see what your system was up to
> > just before a crash? 
> 
> I've done that, with no real hints.  That's the first thing any linux
> admin does when confronted with an issue such as this, no?

Sure. But your first post gave no indication that you did that.

> Is there
> perhaps a way to build Thunderbird with debug symbols or some kind of
> logging?  I seem to recall opening Thunderbird each time this issue has
> showed up.

Well it would be nice to confirm that it is indeed at fault; downgrading
it is certainly not a "REAL mess" either. You can certainly also build
it with debug symbols: in the PKGBUILD (or makepkg.conf), set
CXXFLAGS='' LDFLAGS='' CFLAGS='-g' and remove the strip option.

> I'm ready
> to blame btrfs b/c that's the only issue I see with my setup -- I also
> have a tough time running a virtual machine on this box which I believe
> is also due to btrfs.

Didn't you write just a few lines ago that btrfs "has nothing at all to
do with the issue"?

Wild guess: your thunderbird mail database is huge (just like the disk
image of your virtual machine - although I cannot really know what you
mean by "tough time") and your btrfs has problems dealing with such big
files (for instance, because your filesystem nearly full). To confirm,
start thunderbird with an empty profile (such as by renaming ~/.mozilla
into ~/.mozilla.old) and see what happens.

-- 
Gaetan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20130207/42818582/attachment-0001.asc>