<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000099">
Roger Heflin wrote:
<blockquote cite="mid:48AF2005.3010909@gmail.com" type="cite">
<pre wrap="">Jonathan Heizer wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hey all,
I have a master backend that has been running .21 fixes for a few months
perfect. As of a couple nights ago it started hard locking up over
night. This machine only runs myth and its DB. The best guess I have
had so far is maybe it has to do with mythfilldatabse running grabbing
data from schedules direct. There is nothing in the log files to help
out. My only guess on when it is going down has been from gaps in log
files starting between 1 and 4 am. I tried running a --refresh-all a
little while ago and it appeared to finish ok, but about 30 minutes
later I realized the machine had locked up again. I am not sure exactly
when the fill finished and how long until it locked as I got sucked into
work and missed it finishing. I ran a straight mythfilldatabase and all
was fine, and am running another --refresh-all now to see if it will
happen again.
Based on the temp logs it is not over heating. Once it is down there is
no ping response or lighting up of caps key on KB or anything.
Completely dead.
root@mythtv:~# uname -a
Linux mythtv 2.6.18-chw-13 #1 SMP PREEMPT Tue Mar 6 19:57:00 PST 2007
i686 GNU/Linux
root@mythtv:~# mythfrontend --version
Please include all output in bug reports.
MythTV Version : 17338
MythTV Branch : branches/release-0-21-fixes
Library API : 0.21.20080304-1
Network Protocol : 40
Options compiled in:
linux release using_oss using_alsa using_arts using_jack using_backend
using_dbox2 using_directfb using_dvb using_firewire using_frontend
using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc
using_opengl_vsync using_v4l using_x11 using_xrandr using_xv using_xvmc
using_xvmcw using_xvmc_vld using_bindings_perl using_bindings_python
using_opengl using_ffmpeg_threads using_libavc_5_3 using_live
Mostly just wondering if anyone else has had this problem pop up in the
last few days.
Thanks,
Jon
</pre>
</blockquote>
<pre wrap=""><!---->
It is very difficult for a user application to take a machine out (not
impossible, but pretty rare, it requires either a kernel bug, or the application
to use up all of memory).
If you are running at runlevel 3 or running X I would start running runlevel 3
and don't run X (if you can) and see if you get any useful kernel messages when
it crashes, I expect that you might, but they will likely vary from crash to
crash, it is very likely this is some sort of hardware issues, but you may get
kernel messages that will point to one piece of HW or another.
memtest might be a good start, as memory is one of the most likely failure items.
Roger</pre>
</blockquote>
Good idea killing X so I can hopefully see kernel messages. As stable
as this machine has been for years, I would hate for it to be a
hardware problem, but it has to happen eventually right. Just been
surprised we can watch hours of HD Olympics during the evening, then it
crash overnight while idling. Was planning on running a memtest this
evening and hopefully that comes back clean, or bad so I know what is
wrong lol.<br>
<br>
Thanks<br>
<br>
<br>
</body>
</html>