From what I understand, in MythTV 0.27 there is a --disable-logserver configure option that, when set, causes MythTV to log as it used to use file logging from the individual processes directly without mythlogserver as was the case prior to it's addition. Apparently, the new command line --nologserver option does not work for this and forces console logging. As I understand it, a number of distributions are packaging with this option. I plan on enabling this in my overlay when I upgrade, and was wondering if a local USE flag might be a good idea for this one. Thanks. Reproducible: Always
NOTE: My mistake. The correct configure option is --disable-mythlogserver.
Just a note. I just upgraded using the mythtv-0.27_p20131124.ebuild in my local overlay with this: 247a248,250 > # ADDED BY TOM > myconf="${myconf} --disable-mythlogserver" > ...and it worked great. Everything is logging to /var/log/mythtv with no mythlogserver as expected.
I discovered an additional complication with this on unfortunately. That's the fact that the logrotate config that's packaged with 0.27, naturally, is set up to send a hup signal to mythlogserver. Worse yet, I'm finding that even with the configuration I'm using which is much like the pre-mythlogserver configuration, the HUP signal no longer appears to be opening new log files, and I'm finding my backend actively writing to rotated files. I just queried the mailing list to figure out what's going in there.
(In reply to Tom Dexter from comment #3) > I discovered an additional complication with this on unfortunately. That's > the fact that the logrotate config that's packaged with 0.27, naturally, is > set up to send a hup signal to mythlogserver. > > Worse yet, I'm finding that even with the configuration I'm using which is > much like the pre-mythlogserver configuration, the HUP signal no longer > appears to be opening new log files, and I'm finding my backend actively > writing to rotated files. I just queried the mailing list to figure out > what's going in there. Thanks for catching this. I do intend to support this configuration, so let me know whether patches/etc emerge (they're usually good about backporting this sort of thing, but if necessary I'll backport it myself if reasonably straightforward).
(In reply to Richard Freeman from comment #4) > (In reply to Tom Dexter from comment #3) > > Thanks for catching this. I do intend to support this configuration, so let > me know whether patches/etc emerge (they're usually good about backporting > this sort of thing, but if necessary I'll backport it myself if reasonably > straightforward). I briefly looked at the code myself and have been back and forth on the mailing list on this one in this (somewhat unrelated) thread: http://www.gossamer-threads.com/lists/mythtv/users/560196 As far as I can see the SIGHUP logic to reopen the logs currently exists ONLY in the mythlogserver code. So apparently, with --disable-mythlogserver, as far as I can see, there is no workable way to use logrotate...at least none that rely on sending a HUP to the backend or frontend. Way back I used to use copytruncate settings, which doesn't require the HUP'ing the processes, but isn't workable with the newer log file naming. The only suggestions involved using syslog which of course is a huge can of worms as discussed here: https://bugs.gentoo.org/show_bug.cgi?id=426242#c8 The way it stands I may end up throwing in the towel and just using mythlogserver, and hoping for the best, though I really didn't want to.
I've been running mythtv .20 for something like 6 years now, and am looking to finally upgrade onto new hardware, most likely with .27. I don't particularly like the concept of the logserver either. They've actually demoted it in .27, it's considered intended for debugging purposes only, not general operation. Personally, I'm just going to use syslog. I'm not sure what the difference is as far as "losing" logs (the point of mythlogserver) between each app syslogging directly or going through mythlogserver, the issue would only be if each app was writing directly to a file and a log entry was lost in a buffer when it crashed. Too bad they dropped log rotation from the individual apps, maybe they'll bring that back now that they've moved mythlogserver to debugging status. How about a "syslog" use flag that adds --disable-mythlogserver and doesn't install the logrotate file? So +syslog would mean syslog *only* (as file logging isn't very useful without rotation) and -syslog would enable mythlogserver and let you do direct to file logging (and still syslog I guess, but if you were doing syslog I don't see why you'd want mythlogserver). If you're using syslog, by default it will all get dumped to /var/log/messages, which is already rotated by default. And if you tweak the syslog config to split it out, you can also own updating logrotate config. +syslog could also tweak the mythbackend conf.d to add --syslog to MYTHBACKEND_OPTS. That works for me... On a side note, why doesn't the mythtv ebuild use econf? I'd rather not make a copy of the ebuild to add --disable-mythlogserver, it would be cleaner to just supply EXTRA_ECONF, but since it doesn't use econf... If for some reason configure has to be called manually, maybe you could tweak it to add ${EXTRA_ECONF} to the invocation? Thanks...
I'm assuming there's still no decision on changing the logging config, but any chance you could tweak the new ebuilds to use econf, or at least to add ${EXTRA_ECONF} to the invocation so people can disable the logserver without having to copy the ebuild into a local overlay and edit it? Thanks...
Just another ping on adding a use flag to disable the logserver, or adding econf support/${EXTRA_ECONF} to ebuild so logserver can be disabled without needing a local copy of the ebuild. Thanks...
(In reply to Paul B. Henson from comment #8) > Just another ping on adding a use flag to disable the logserver, or adding > econf support/${EXTRA_ECONF} to ebuild so logserver can be disabled without > needing a local copy of the ebuild. > > Thanks... I did improve the systemd units slightly along these lines, though I didn't go as far as this. The trick is trying to coordinate these kinds of changes with the init.d/systemd changes so that it all makes sense. Part of me wonders if it makes more sense to try to make disabling the logserver the default and then organize the init.d/system configs around that. My understanding is that this is the long-term goal for 0.28 anyway. I just don't want to make a reconfiguration mess for everybody either - maybe I should check upstream to make sure I understand the plans for 0.28 so that we can have one migration.
econf support/${EXTRA_ECONF} in the ebuild would be openrc/systemd agnostic, no? I don't care too much what the default is (although +1 for disabled :) ), I'd just like a way to change it without copying the ebuild to an overlay. My understanding is that the logserver is deprecated and will be removed, but I don't know for sure in what version. Thanks...
Any new thoughts on this :)? You resolved one of my other issues by adding the wrapper use flag, but I still needed to make a local ebuild for my current upgrade to 0.27.5_p20150627 to disable the logserver. It seems adding econf support/${EXTRA_ECONF} would be fairly simple, and future change agnostic? Thanks...
(In reply to Paul B. Henson from comment #11) > Any new thoughts on this :)? You resolved one of my other issues by adding > the wrapper use flag, but I still needed to make a local ebuild for my > current upgrade to 0.27.5_p20150627 to disable the logserver. It seems > adding econf support/${EXTRA_ECONF} would be fairly simple, and future > change agnostic? > > Thanks... So you should be able to use EXTRA_ECONF today. The base "econf" command in at least EAPI=5 supports it by default which is what the current 0.27.5 ebuild uses.
As far as the original request in the bug report goes, I'm adding the following to the next version bump: # Configures where mythbackend logs # Valid values: # * files - logs each individual daemon in /var/log/mythtv (default) # * database - logs into the database # * syslog FACILITY - logs to syslog using FACILITY (see syslog(3)) # * console - logs only to the console (no mythlogserver) #MYTHBACKEND_LOGGING="files"
Thanks for the report. Fixed in http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9ada29b52010e465a522fdc68d4eee0da6eaa349
