On Wed, Jul 03, 2019 at 03:26:36PM +0000, Jim Fehlig wrote:
On 7/3/19 2:42 AM, Daniel P. Berrangé wrote:
> On Wed, Jul 03, 2019 at 08:55:15AM +0200, Peter Krempa wrote:
>> On Wed, Jul 03, 2019 at 08:32:21 +0200, Jan Zerebecki wrote:
>>> On 03/07/2019 08.03, Peter Krempa wrote:
>>>> I'm not sure that this is the right thing to do. virtlogd has some
>>>> internal log rotation mechanisms
>>>
>>> logrotate is already in use here and this patch doesn't change what is
>>> rotated nor how often it is rotated.
>>>
>>>> and also the SIGUSR1 action is reserved
>>>> for re-exec updates and not for dealing with modified files
>>>
>>> The mechanism (re-exec) and implementation details for both uses do not
>>> conflict.
>>
>> The problem is that the logrotate configs predate use of virtlogd and I
>> don't think they were adapted to be used together. In fact if I remember
>> correctly the idea of virtlogd was to avoid using logrotate altogether.
>
> Yes, logrotate should not be in effect when virtlogd is running. We should
> ensure that logrotate rollover size is *larger* than the rollover size
> configured for virtlogd. This would ensure virtlogd rolls over first, and
> thus when logrotate runs it should see nothing todo.
Hmm, it sounds like the proper fix is to simply remove
src/remote/libvirtd.qemu.logrotate.in?
We didn't want to remove it because whether or not to use virtlogd is
a config file tunable. Hence we want to make sure that its default
settings end up being a no-op if virtlogd has already done its own
rollover
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|