<br><br><div class="gmail_quote">On 18 April 2012 10:43, Michael Watson <span dir="ltr"><<a href="mailto:michael@thewatsonfamily.id.au">michael@thewatsonfamily.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 18/04/2012 10:35 AM, Frank Phillips wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Tue, Apr 17, 2012 at 7:07 PM, Jerry Rubinow <<a href="mailto:jerrymr@gmail.com" target="_blank">jerrymr@gmail.com</a> <mailto:<a href="mailto:jerrymr@gmail.com" target="_blank">jerrymr@gmail.com</a>>> wrote:<br>
<br>
On Tue, Apr 17, 2012 at 9:02 AM, Mark Lord <<a href="mailto:mythtv@rtr.ca" target="_blank">mythtv@rtr.ca</a><br></div><div><div class="h5">
<mailto:<a href="mailto:mythtv@rtr.ca" target="_blank">mythtv@rtr.ca</a>>> wrote:<br>
<br>
On 12-04-16 11:36 PM, Jerry Rubinow wrote:<br>
> My mythbackend computer locked up today, the whole computer,<br>
not just mythbackend. Following is the<br>
> syslog at the time this happened. It's been rock steady for<br>
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<br>
disk errors?<br>
..<br>
<br>
No, not with the scanty information provided.<br>
If there are disk errors, then there will be kernel logs along<br>
with them.<br>
<br>
Also, "smartctl -a /dev/sdX" will give very good information<br>
about the error state of the drives.<br>
<br>
<br>
Thanks Mark. kern.log had the same info as syslog, and smartctl<br>
wasn't revealing. Sorry for the scanty info, but I'm not sure<br>
what direction to look.<br>
<br>
Once more piece of data is that I saw a very high load before it<br>
completely locked up, but the top items in top were not using much<br>
cpu.<br>
<br>
<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>
<br>
</div></div></blockquote>
I find "smart" almost useless with physical problems on hard drives. I find hddtemp in combination with a logging function like cacti or mrtg to show up physical hard drives better. (The temperature tends to go high when the disk is having physical issues)<br>
<br>
Try a 'cat /var/log/syslog | grep sdX'. Might reveal something. You might want to go through each of your hard drives (sda, sdb, etc) if you have more than one.<br>
<br>
<br>
<br>
</blockquote></div>Hi Michael, <br><br>OT but can you provide your cacti scripts your using for hddtemp?<br><br>Cheers,<br><br>Anthony<br>