[mythtv-users] Myth FE, mythfilldatabase, and NFS Issue

[James Crow]

Michael T. Dean wrote:
> On 03/20/2009 10:02 AM, James Crow wrote:
>> Last night I was watching a recorded show and my FE locked up. The 
>> picture was frozen on screen and the keys pressed on the remote 
>> seemed to be ignored. I went to my main desktop and sshed into the FE 
>> machine. The system was not hard locked and I was able to kill 
>> mythfrontend. I started looking at log files to see if I could find a 
>> cause. It appears that the NFS daemon on the master BE was no longer 
>> responding. This caused the FE to lock up. I restarted NFS on the MBE 
>> and started the FE back up and everything appeared fine.
>>
>> Just as a precaution I looked at the BE log and /var/log/messages. 
>> Right near the time that the NFS daemon stopped responding 
>> mythfilldatabase had segfaulted. Has anyone seen similar behavior or 
>> know how to better test mythfilldb?
>>
>> /var/log/messages from MBE:
>> Mar 19 21:02:03 mythfront -- MARK --
>> Mar 19 21:21:22 mythfront kernel: [790809.097285] nfsd: last server 
>> has exited, flushing export cache
>> Mar 19 21:21:24 mythfront kernel: [790810.437165] NFSD: Using 
>> /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
>> Mar 19 21:21:24 mythfront kernel: [790810.437548] NFSD: starting 
>> 90-second grace period
>> Mar 19 21:42:03 mythfront -- MARK --
>> Mar 19 22:02:03 mythfront -- MARK --
>> Mar 19 22:22:03 mythfront -- MARK --
>> Mar 19 22:41:36 mythfront kernel: [795622.497755] 
>> mythfilldatabas[21487]: segfault at 162e2c0 ip 000000000162e2c0 sp 
>> 0000000042320dd8 error 15
>> Mar 19 23:02:06 mythfront -- MARK --
>>
>> mythfilldatabase segfaulted again this morning:
>> Mar 20 08:42:06 mythfront -- MARK --
>> Mar 20 08:53:26 mythfront kernel: [832333.266066] 
>> mythfilldatabas[27033]: segfault at 103a660 ip 000000000103a660 sp 
>> 00000000413c7dd8 error 15
>> Mar 20 09:22:06 mythfront -- MARK --
>>
>> I am not sure if the nfs issue and the segfault are connected, but it 
>> seems odd that occurred at nearly the same time. 
>
> Not having any advice for configuring/fixing your NFS, I will say that 
> the symptoms you saw are exactly what should happen if the recording 
> suddenly disappears.  Perhaps someone here has some suggestions for 
> making a more stable NFS configuration.  (Note, also, that I've heard 
> a lot of MythTV people (haven't read any distro wiki's/fora, though) 
> complaining about the instability of NFS in, at least, recent Ubuntu 
> versions.)
>
> Mike

NFS instability is definitely part of the problem. I don't know if it is 
a symptom of maybe buggy NIC drivers or perhaps the actual problem. I 
know that the recording disappeared. I actually tried to restart 
mythfrontend and then when I got to the Watch Recordings screen things 
froze again. The system log on the FE had a message about unable to 
connect to NFS server on 192.168.253.51. That is what prompted me to 
restart nfs.

I could also enable streaming from the MBE through the Myth protocol, 
but I was under the impression that NFS would use fewer resources. I 
wonder if I/O starvation would cause the NFS faults. I have a single 
dedicated recording drive on my MBE and was recording two SD shows 
(PVR-500) and one HD (QAM) recording. At the same time at least one or 
maybe two shows were being commflagged and then I was watching another 
HD show. I don't know what the maximum I/O bandwidth is on a Seagate 
SATAII drive (7200.10), but I could be getting close. I/O starvation 
would produce video pauses on the FE. I did experience some of that 
before the complete loss of the stream.

I think I will try a different NIC this weekend. I currently run with 
the onboard nforce 4 ethernet. It is only 100MB and I recall having some 
issues with older linux kernels not working well with it. I have a SBE 
that has gig ethernet and my switch is gigabit so if nothing else a new 
nic would give me some increased speed between them.

I guess it is time to read up on logging for nfs and see if it logs some 
error the next time this happens.

Thanks,
James