[mythtv-users] mythbackend hanging with busy disk

[HP-mini]

On Thu, 2016-04-07 at 14:35 +1200, Stephen Worthington wrote:
> On Wed, 6 Apr 2016 19:30:10 +0200, you wrote:
> 
> >My mythbackend hangs from time to time with a busy disk.
> >
> >It is not reproducible, but happens every couple of days.
> >
> >When it happens, I cannot log in via ssh, and mythweb is also
> >unresponsive. The one time I happened to be already logged in via ssh,
> >htop showed that it was not CPU-bound.
> >
<snip>
> 
> My experiences with a "busy disk" (continuous disk activity but unable
> to get the box to do anything, or it taking many minutes to do
> something that normally is instant) have all been one of two things:
> 
> 1) Disk thrashing - where there are two or more sources of ultra-heavy
> disk activity, each causing so much activity that the other can not
> make any progress.  If you have mythcommflag running on multiple
> recordings (started at the end of the recording) and a database backup
> happening at the same time, you will likely get disk thrashing (unless
> it is an SSD).
> 
> 2) Disk full.  This is usually caused by log files filling up the
> disk, due to some problem that does not properly control the resulting
> log messages, or say a DDNS attack on a router causing massive traffic
> from it.  But I have also had a MythTV backup to the same disk as the
> database causing it to go full.  My database is always growing and is
> now huge, so the backup process, which creates an ASCII SQL dump of
> the database first, then compresses it with gzip, was overflowing the
> disk, either in the first stage of creating the dump, or when it
> needed to create new file to compress that dump into.  So check where
> your backups are going and the relative size of your database versus
> the free space.  The database is normally in
> /var/lib/mysql/mythconverg and backups default to going to
> /var/lib/mythtv/db_backups.
> 
> The "PMT says program xxxx is encrypted" messages may or may not be a
> problem.  The PMT is a Program Map Table in the MPEG2 transport
> stream.  See here for basic information about how MPEG2 transport
> streams work:
> 
> https://en.wikipedia.org/wiki/MPEG_transport_stream
<snip>

A 3rd can be due to a process consuming all RAM & then eating swap space
until a kernel out-of-memory protection mechanism kills the rogue
process.
This can take a couple minutes to clear.
Mythfrontend does this (here) when using RSS news feeds to access
Gizmodo website (crash seems to be in Qt5).