[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