[mythtv-users] --logfile vs. --logpath

[R. G. Newbury]

On 05/19/2012 05:13 AM, Michael T. Dean wrote:
> On 05/18/2012 11:11 PM, R. G. Newbury wrote:
>> On 05/18/2012 01:40 PM, Michael T. Dean wrote:
>>> On 05/18/2012 01:35 PM, R. G. Newbury wrote:
>>>> On 05/18/2012 12:53 PM, Gavin Hurlbut wrote:
>>>>> The value is for debugging and diagnosis of issues. Without the logs
>>>>> you can not get any support at all. Disk space is cheap. Just prune
>>>>> them out every few days or so and they will stay under control just
>>>>> fine.
>>>>>
>>>>> If you delete the files every minute, you are likely to mess things
>>>>> up.
>>>>> I, for one, will not even attempt to support a system with that setup.
>>>>>
>>>>
>>>> OK, so I will set the cron to delete them every hour or so..
>>>
>>> Still seems like overkill. Are you really concerned about using a couple
>>> megabytes of HDD space in a day (and even a couple megabytes/day is
>>> quite a lot for mythpreviewgen)?
>>>
>>>> And turn off the cron job if I need to debug anything.
>>>> But I have never had a problem with preview generation.
>>>
>>> If you really do have a problem with it, you can use syslog logging, and
>>> just tell your syslog logger to throw away all mythpreviewgen log
>>> output. That said, I'm guessing there are other issues on your MythTV
>>> computers that deserve more attention than complete eradication of
>>> mythpreviewgen log files... ;)
>>
>> Well I will end up doing something. ATM the logging scheme seems to me
>> to be disfunctional. I'm going to have to read the wiki and play with
>> the settings. Try logrotate, or syslog or cron.
>> Myth now seems to spew logging files. I changed the loglevel to crit,
>> in an attempt to reduce the output, but now the files don't report
>> much of anything.
>> Uptime is 49 days, I have about a dozen backend logfiles all dated
>> April 29 and nothing after that. I have 4 frontend files dated April
>> 29 and one dated May 3 and nothing after that. loglevel at crit may be
>> too high.
>> I liked the old logfile scheme: one process one file.
>
> Actually, it was "one process and all its subprocess, one file full of
> mixed up log messages" that resulted in users saying, "The backend
> locked up with 'invalid protocol version' error," which is impossible (a
> backend can't have an invalid protocol version with itself). What was
> actually happening was some child process started by the backend was
> failing due to the backend's network/socket code failing to listen
> for/respond to clients. Now, users would correctly report,
> "mythpreviewgen runs fail due to 'invalid protocol version' and
> mythbackend doesn't respond to network requests," because they won't see
> mythpreviewgen logging in mythbackend.log, so they'll actually know
> where it's coming from/what's happening.

That aspect of it I understand and I agree with. I still have to learn 
how to handle the spew of files which the new methodology produces. I 
don't mind one file per process/subprocess. I just don't find the 
present method particularly usable due to the fact that I have to open 
and look at so many files to find anything. And what I presently see is 
not too useful to me. That may be that I have the error level turned up 
too high, so I don't see the 'normal' reporting I am used to.

And logrotate or syslog or cron will have to be instituted to deal with 
it all.

G.