Log reopen broken in 2.2.33?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Log reopen broken in 2.2.33?

Dave-2

Has re-opening the logfiles broken between 2.2.32 and 2.2.33 releases?

Using the same config that I've had for the past 10 or so point
releases, /usr/bin/doveadm log reopen works perfectly up until 2.2.32,
but with 2.2.33 (and .1 and .2) no new logfiles are created, file
descriptors still have the original files open and keep writings to
those logs. On an idling test instance, I get:

master: Warning: Sent SIGKILL to 1 log processes

I can see both SIGUSR1 and SIGKILL generated by the master process, but
the current log process doesn't terminate - it receives SIGUSR1, but not
SIGKILL. Anyone able to verify this on their own setup? Am I missing a
required config change? Using epoll, which hasn't changed.

--
David Zambonini
Reply | Threaded
Open this post in threaded view
|

Re: Log reopen broken in 2.2.33?

Aki Tuomi-2


On 06.11.2017 23:31, David Zambonini wrote:

> Has re-opening the logfiles broken between 2.2.32 and 2.2.33 releases?
>
> Using the same config that I've had for the past 10 or so point
> releases, /usr/bin/doveadm log reopen works perfectly up until 2.2.32,
> but with 2.2.33 (and .1 and .2) no new logfiles are created, file
> descriptors still have the original files open and keep writings to
> those logs. On an idling test instance, I get:
>
> master: Warning: Sent SIGKILL to 1 log processes
>
> I can see both SIGUSR1 and SIGKILL generated by the master process, but
> the current log process doesn't terminate - it receives SIGUSR1, but not
> SIGKILL. Anyone able to verify this on their own setup? Am I missing a
> required config change? Using epoll, which hasn't changed.
>
Hi!

Thank you for your report, we'll investigate it.

Aki
Reply | Threaded
Open this post in threaded view
|

Re: Log reopen broken in 2.2.33?

Aki Tuomi-2


On 07.11.2017 08:54, Aki Tuomi wrote:

>
> On 06.11.2017 23:31, David Zambonini wrote:
>> Has re-opening the logfiles broken between 2.2.32 and 2.2.33 releases?
>>
>> Using the same config that I've had for the past 10 or so point
>> releases, /usr/bin/doveadm log reopen works perfectly up until 2.2.32,
>> but with 2.2.33 (and .1 and .2) no new logfiles are created, file
>> descriptors still have the original files open and keep writings to
>> those logs. On an idling test instance, I get:
>>
>> master: Warning: Sent SIGKILL to 1 log processes
>>
>> I can see both SIGUSR1 and SIGKILL generated by the master process, but
>> the current log process doesn't terminate - it receives SIGUSR1, but not
>> SIGKILL. Anyone able to verify this on their own setup? Am I missing a
>> required config change? Using epoll, which hasn't changed.
>>
> Hi!
>
> Thank you for your report, we'll investigate it.
>
> Aki
Hi!

This has been fixed with
https://github.com/dovecot/core/commit/84703c2f19113ac731e4638ba782fa87e0748ba6
Reply | Threaded
Open this post in threaded view
|

Re: Log reopen broken in 2.2.33?

Dave-2
On 07/11/2017 08:37, Aki Tuomi wrote:

>
>
> On 07.11.2017 08:54, Aki Tuomi wrote:
>>
>> On 06.11.2017 23:31, David Zambonini wrote:
>>> Has re-opening the logfiles broken between 2.2.32 and 2.2.33 releases?
>>>
>>> Using the same config that I've had for the past 10 or so point
>>> releases, /usr/bin/doveadm log reopen works perfectly up until 2.2.32,
>>> but with 2.2.33 (and .1 and .2) no new logfiles are created, file
>>> descriptors still have the original files open and keep writings to
>>> those logs. On an idling test instance, I get:
>>>
>>> master: Warning: Sent SIGKILL to 1 log processes
>>>
>>> I can see both SIGUSR1 and SIGKILL generated by the master process, but
>>> the current log process doesn't terminate - it receives SIGUSR1, but not
>>> SIGKILL. Anyone able to verify this on their own setup? Am I missing a
>>> required config change? Using epoll, which hasn't changed.
>>>
>> Hi!
>>
>> Thank you for your report, we'll investigate it.
>>
>> Aki
> Hi!
>
> This has been fixed with
> https://github.com/dovecot/core/commit/84703c2f19113ac731e4638ba782fa87e0748ba6

Thanks Aki (and Timo!) - very fast work there, confirmed the patch fixes here.

--
David Zambonini