michael at thewatsonfamily
Mar 7, 2012, 3:37 PM
Post #5 of 13
On 8/03/2012 4:42 AM, Michael T. Dean wrote:
Re: [mythtv-commits] mythtv/master commit: fd1800a11 by Gavin Hurlbut (Beirdo)
[In reply to]
> On 03/07/2012 07:01 AM, Stuart Morgan wrote:
>> On Wednesday 07 Mar 2012 11:37:02 Paul Harrison wrote:
>>> On 06/03/12 20:53, MythTV wrote:
>>>> Author: Gavin Hurlbut<ghurlbut [at] mythtv>
>>>> Change Date: 2012-03-06T12:51:02-08:00
>>>> Push Date: 2012/03/06 12:53:16 -0800
>>>> Repository: mythtv
>>>> Branch: master
>>>> New Revision: fd1800a11f041b63a3d7dc6365155b79529a99fa
>>>> Changeset: https://github.com/MythTV/mythtv/commit/fd1800a11
>>>> Remove --logfile and -l parameters
>>>> As there is no need to use --logfile anymore (use syslog functionality
>>>> instead) and to force the update of old startup scripts that use -l
>>>> (also for logfile), these command-line parameters have been removed.
>>> There's going to be a lot of angry user wondering why there BE wont
>>> start up only to find it's complaining about an unknown --logfile
>>> command. Seem like a very strange decision to knowingly break peoples
>> Agreed, this is going to break all existing init scripts.
> The problem is that if these users don't fix their init scripts to use
> --logpath, their setup is broken, anyway. With --logfile, the program
> is told it can write to the specified log file and only the specified
> log file. Since the new logger no longer puts messages from child
> processes into the same log file, that means that there is no logging
> for the child processes.
> Logging to the same log file results in confused bug reports where
> people say things like, "Master backend locks up with invalid protocol
> version," (where, in fact, some child program--like
> mythpreviewgen--called by the master backend tried to connect to the
> master backend and got the invalid protocol version message, but it got
> thrown into the master backend log, so the user thought the master
> backend was saying the protocol version had somehow become invalid).
> The decision was made that if the user specified a log file, they were
> not providing permission for us to write to other files in the same
> directory. Therefore, unless users run with --logpath, they are not
> getting proper logging, and we'll be left with a lot of angry users
> wondering why their previews and commercial detection and transcoding
> and metadata and ... aren't working--but with absolutely no way to find
> out because they don't know they're using a broken log option.
> This seems like the approach that is most likely to help them notice the
> configuration is broken and fix it. And, FWIW, it seems that the
> approach works--we've already had one user (Blazej) report that he was
> "inspired" by this commit to fix his start script. :)
> And, to paraphrase a smart developer's comments in IRC, if a user is
> experienced enough to compile MythTV and write his own start scripts, he
> should be experienced enough to know to test running the program in a
> terminal to see any errors when it fails to start in the start script,
> and experienced enough to edit the start script. If the user is using a
> packaged version of MythTV, the packagers should be providing working
> start scripts that work and that use proper logging (i.e. like Ubuntu
> provides a script that starts MythTV and uses the syslog logger).
> So, if we release 0.25 with --logfile allowed, users will be lacking log
> output that they'll need to figure out why things don't work.
Why not place a message in file specified in --logfile of the changes
required to fix the setup, and allow backend to carry on without logging.
mythtv-dev mailing list
mythtv-dev [at] mythtv