[BlueOnyx:26073] Re: Nightly logrotate errors
Juerg Sommer
jsommer at emailto.ch
Wed Apr 5 00:54:06 -05 2023
Hi Michael
>>> /usr/sausalito/sbin/update_vsite_logrotate.pl does not? I checked
>>> the script,
>>> I think it would, but I'm not sure. Otherwise Michael has to answer
>>> this
>>> question, I'm not sure about this.
>> I'll see if it did in a few hours 😉
>
> Yes, please let us know if it made a difference. I'll look into the
> scripts again to see if and how we can fix incorrectly set UID/GIDs
> for the logfiles. What we currently have in place is a bit crude and
> that stuff could use an overhaul.
>
Thanks. In my case, the logrotate-file /etc/logrotate.d/site2 had wrong
uid/gid:
su SITE7-logs site7
Don't know if Florian issue is the same, but error messages looks alike.
In my case site2 and site7 exists, so chown to SITE7-logs doesn't
generated an error, but site2 was heavly used, site7 only a httpd-proxy
with 50M site quota, so the owned logfiles by SITE7-logs instead of
SITE2-logs generated quota errors on my server.
Maybe migration renames the file but doesn't update the content of the
/etc/logrotate/siteX. As written before, the problem was not
reproducable and only occured after one-time migration. But now Florian
has probably the same issue after site migration.
Regards,
Juerg
More information about the Blueonyx
mailing list