Comment 3 for bug 722274

Jim,

On Sun, Feb 20, 2011 at 5:34 PM, Jim Patterson
<email address hidden> wrote:
> This bug seems to be a "next day" kind of thing. I only see it after
> coming back to the system from not working on it for a while. If you
> stop Apache, manually remove the latest log files, then run
> catalog_update.inc and finally restart apache, then as long as logging
> was enabled, I think you'll be able to reproduce the bug. That's a bit
> easier to set up than the actual circumstance, which seems to happen if
> the catalog update job gets run before anyone or anything hits the
> ampache web site on a given day.

This is indeed a unusual use case (my home server never gets
shutdown). I will set this up in a vm tonight to see if I can
reproduce this behavior in the current development branch.
>
> I don't think removing the current date from the log file name will
> rectify the problem.

As stated earlier, the date was removed so logrotate can operate correctly

If logrotate is periodically compressing and
> renaming log files, there will still be a window after a logrotate
> operation where catalog_update.inc could be run and trigger the issue.
> The key factor here is whether the log files exist when this job runs.
> If they aren't, and if any logging is done, then the log files will end
> up being owned by root/root instead of www-data/www-data.

If need be the catalog_update.inc cron job can be removed, as this is
not a critical feature for ampache to operate.

Charlie Smotherman

--
Charlie Smotherman
Debian Contributor
Ubuntu Developer