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

[Michael T. Dean]

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.

Mike