[mythtv] [mythtv-commits] mythtv/master commit: fd1800a11 by Gavin Hurlbut (Beirdo)

[Michael T. Dean]

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.org>
>>>   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
>>>
>>> Log:
>>>
>>> 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.
>>>
>>> Modified:
>>>     mythtv/libs/libmythbase/mythcommandlineparser.cpp
>> 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
>> setups.
> 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.

Mike