On 6/27/05, Robert Tsai <[EMAIL PROTECTED]> wrote:
*snip*
> This looks syntactically correct, but won't achieve what you want.
> Mythbackend still has the logfile open, so even though the logfile has
> been truncated, the space will not be returned to the filesystem until
> the logfile has been clo
On Mon, Jun 27, 2005 at 10:10:21PM +1000, Chris Edwards wrote:
> On 6/27/05, Phill Edwards <[EMAIL PROTECTED]> wrote:
> > > Are you using the copytruncate option in the logrotate entry for
> > > mythtv?
> >
> > No I haven't been so I will give that a go. Thanks for the
> > suggestion. My mythbacke
On 6/27/05, Phill Edwards <[EMAIL PROTECTED]> wrote:
> > Are you using the copytruncate option in the logrotate entry for mythtv?
>
> No I haven't been so I will give that a go. Thanks for the suggestion.
> My mythbackend file for logrotate now looks like this:
>
> /var/log/mythtv/mythbackend.log
> > Does anyone know how to fix this? Mythbackend seems to be the only
> > service which this happens to where it can't write to the new log file
> > after logrotate. I know it's possible to stpo/restart the service as
> > part of logrotate but that would mess up the recording.
>
> Are you using t
On 6/27/05, Phill Edwards <[EMAIL PROTECTED]> wrote:
*snip*
> Does anyone know how to fix this? Mythbackend seems to be the only
> service which this happens to where it can't write to the new log file
> after logrotate. I know it's possible to stpo/restart the service as
> part of logrotate but th
My logrotate script runs weekly. I have noticed that I am getting an
error reported form the cron job which says something like "logrotate
resulted in an error" (can't remember the exact wording). This
coincides with a new mythbackend.log file which is 0 bytes and which
doesn't get written to. If I
