<div class="gmail_quote">On Tue, Apr 17, 2012 at 8:35 PM, Frank Phillips <span dir="ltr"><<a href="mailto:frankalso@gmail.com">frankalso@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Tue, Apr 17, 2012 at 7:07 PM, Jerry Rubinow <span dir="ltr"><<a href="mailto:jerrymr@gmail.com" target="_blank">jerrymr@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_quote">
<div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>On Tue, Apr 17, 2012 at 9:02 AM, Mark Lord <span dir="ltr"><<a href="mailto:mythtv@rtr.ca" target="_blank">mythtv@rtr.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 12-04-16 11:36 PM, Jerry Rubinow wrote:<br>
> My mythbackend computer locked up today, the whole computer, not just mythbackend. Following is the<br>
> syslog at the time this happened. It's been rock steady for months, and I haven't made any changes<br>
> lately. I rebooted and now it seems to be functioning normally.<br>
><br>
> Any suggestions for what I should do? Is this a sign of disk errors?<br>
</div>..<br>
<br>
No, not with the scanty information provided.<br>
If there are disk errors, then there will be kernel logs along with them.<br>
<br>
Also, "smartctl -a /dev/sdX" will give very good information<br>
about the error state of the drives.<br></blockquote><div><br></div></div><div>Thanks Mark. kern.log had the same info as syslog, and smartctl wasn't revealing. Sorry for the scanty info, but I'm not sure what direction to look.</div>
<div><br></div><div>Once more piece of data is that I saw a very high load before it completely locked up, but the top items in top were not using much cpu.</div><span><font color="#888888"><div><br></div>
</font></span></div></blockquote></div></div><div><br> That high load is caused by IO wait, which you can see in top as %wa. The longer the disk takes to complete a task, the more processes backup in the queue, causing a high load to be reported. Look closely at your disk, as it most likely has issues.<br>
</div></div>
</blockquote></div><br><div>I found the following in kern.log, during the reboot after the lock-up, but whether it's from an existing disk problem or a result of the hard reboot, I don't know. Hmm, looking at the kernel logs, it looks like the same thing happened 3 days before, but then no kernel messages for several months before that. I'll try Michael's hddtemp suggestion next (thanks!).</div>
<div><br></div><div><div><div>Apr 16 23:01:58 kenny kernel: [ 3.143740] EXT4-fs (sda1): INFO: recovery required on readonly filesystem</div><div>Apr 16 23:01:58 kenny kernel: [ 3.143753] EXT4-fs (sda1): write access will be enabled during recovery</div>
<div>Apr 16 23:01:58 kenny kernel: [ 3.460171] firewire_core: created device fw0: GUID 0010dc0000d0e4fd, S400</div><div>Apr 16 23:01:58 kenny kernel: [ 4.984099] EXT4-fs (sda1): orphan cleanup on readonly fs</div><div>
Apr 16 23:01:58 kenny kernel: [ 5.021903] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 529531</div><div>Apr 16 23:01:58 kenny kernel: [ 5.021987] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 530065</div>
<div>Apr 16 23:01:58 kenny kernel: [ 5.023394] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 530064</div><div>Apr 16 23:01:58 kenny kernel: [ 5.023438] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 530055</div>
<div>Apr 16 23:01:58 kenny kernel: [ 5.023446] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 529856</div><div>Apr 16 23:01:58 kenny kernel: [ 5.029437] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 524863</div>
<div>Apr 16 23:01:58 kenny kernel: [ 5.029448] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 16515082</div><div>Apr 16 23:01:58 kenny kernel: [ 5.029458] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 16515081</div>
<div>Apr 16 23:01:58 kenny kernel: [ 5.029465] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 16515080</div><div>Apr 16 23:01:58 kenny kernel: [ 5.029472] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 16515079</div>
<div>Apr 16 23:01:58 kenny kernel: [ 5.029528] EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 16515078</div><div>Apr 16 23:01:58 kenny kernel: [ 5.029534] EXT4-fs (sda1): 11 orphan inodes deleted</div>
<div>Apr 16 23:01:58 kenny kernel: [ 5.029539] EXT4-fs (sda1): recovery complete</div><div>Apr 16 23:01:58 kenny kernel: [ 5.217408] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)</div><div>
Apr 16 23:01:58 kenny kernel: [ 15.694142] Adding 980988k swap on /dev/sda5. Priority:-1 extents:1 across:980988k</div><div>Apr 16 23:01:58 kenny kernel: [ 15.844409] <30>udev[378]: starting version 167</div><div>
Apr 16 23:01:58 kenny kernel: [ 16.110580] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro</div></div></div><div><br></div><div>-Jerry</div>