[mythtv-commits] Ticket #11230: mythlogserver high cpu usage
MythTV
noreply at mythtv.org
Fri Apr 25 15:14:47 UTC 2014
#11230: mythlogserver high cpu usage
------------------------------------+------------------------
Reporter: cleanrock@… | Owner: beirdo
Type: Bug Report - General | Status: new
Priority: minor | Milestone: 0.27
Component: MythTV - Mythlogserver | Version: 0.26
Severity: low | Resolution:
Keywords: | Ticket locked: 0
------------------------------------+------------------------
Comment (by mdean):
Because mythlogserver exits after a period of inactivity and because the
mythlogserver process is started, again, by whichever process has new log
messages to write when there is no process already running, mythfrontend--
and any other MythTV process, including mythpreviewgen, mythtranscode,
mythjobqueue, mythcommflag, mythmetadatalookup, ...--can (and will,
eventually, depending on timing) start mythlogserver. Therefore, the fact
that you're running mythfrontend as a different user means this is most
likely what's causing the problem. The problem may also be exacerbated by
different processes being started with different logging instructions
(sometimes direct writing, sometimes syslog, as is shown in comment:14,
above, by barth).
Solutions:
1) Don't use mythlogserver
2) Use syslog logging (for every MythTV application, every single time
it's executed) rather than direct logging so that a different process
(which is always run as the same user--whichever user runs your syslog
daemon) does the actual writing
3) Run mythfrontend as the same user as every other MythTV application on
the host and ensure permissions are correct for the direct-logging
destination
And, yes, we could have code to check for problems so that mythlogserver
fails gracefully. All it requires is for someone to take the time to
write such code. You may call it a bug that MythTV's mythlogserver fails
(spectacularly) when the system is misconfigured, but some may call
mythlogserver's inability to detect and recover from system
misconfiguration a missing feature (mythlogserver, itself, was never
finished due to lack of motivation caused by mass complaints against it).
Note, also, that there are many other misconfigurations (of mythbackend,
mythfrontend, ...) that cause catastrophic failures and we lack code to
handle them, too. If I had unlimited time, I'd write code to handle all
the possible failures, misconfigurations, ... Since I don't, I have to
hope that someone else who feels mythlogserver's lack of graceful recovery
from system misconfiguration (even in light of the future of
mythlogserver) warrants their spending their own time to write code to
handle it more gracefully.
As it is, the rest of the development team has taken the view that
throwing out mythlogserver is the approach to take, so there's no use
writing new code for it. (And, FWIW, if I were fixing things, I would rip
out mythlogserver's "exit on inactivity" functionality (that was included
so users wouldn't complain about an "unnecessary" extra process taking up
resources when there's nothing to log) and make it a normal, always-
running daemon process so it could be started once as a specified user and
just work.)
--
Ticket URL: <https://code.mythtv.org/trac/ticket/11230#comment:21>
MythTV <http://www.mythtv.org>
MythTV Media Center
More information about the mythtv-commits
mailing list