...

Dovecot stops with the following logged:

• master: Fatal: kevent(): Invalid argument

I have found that a diff was created for "src/lib/ioloop-kqueue.c" for a similar issue: http://dovecot.org/pipermail/dovecot/2010-November/054855.html

I have patched my system with this and haven't seen the problem since, but I don't know if this is a coincidence. Could you please explain if the diff should actually fix anything or just add some more logging in case it stops again?

That patch doesn't fix anything. It only changes the error message to be more informative so I could figure out what is causing it. If you haven't seen any more errors, it's just a coincidence.

I have for some reason not seen the error since applying the above patch. But wouldn't it make sense to include the patch in the stable release so others can give input in the rare case they experience the same issue? At least until the issue has been resolved.

I don't say that this is a Dovecot issue, and I admit that it have to be a rare case, but when two independent people experience the same error, there have to be a problem somewhere.

Best regards Henrik Larsson

On 21.5.2011, at 2.51, Henrik Larsson wrote:

...

...

That patch doesn't fix anything. It only changes the error message to be more informative so I could figure out what is causing it. If you haven't seen any more errors, it's just a coincidence.

I have for some reason not seen the error since applying the above patch. But wouldn't it make sense to include the patch in the stable release so others can give input in the rare case they experience the same issue? At least until the issue has been resolved.

I don't say that this is a Dovecot issue, and I admit that it have to be a rare case, but when two independent people experience the same error, there have to be a problem somewhere.

Is there a problem adding a patch like this to the stable code?

Annoying to add ugly debug code for a problem that happens so rarely..

Should I ask the FreeBSD dovecot2 port maintainer to add it to the FreeBSD port instead?

I wouldn't mind them adding it.

On 05/21/2011 17:54, Timo Sirainen wrote:

On 21.5.2011, at 2.51, Henrik Larsson wrote:

...

...

...

That patch doesn't fix anything. It only changes the error message to be more informative so I could figure out what is causing it. If you haven't seen any more errors, it's just a coincidence.

I have for some reason not seen the error since applying the above patch. But wouldn't it make sense to include the patch in the stable release so others can give input in the rare case they experience the same issue? At least until the issue has been resolved.

I don't say that this is a Dovecot issue, and I admit that it have to be a rare case, but when two independent people experience the same error, there have to be a problem somewhere.

Is there a problem adding a patch like this to the stable code?

Annoying to add ugly debug code for a problem that happens so rarely..

...

Should I ask the FreeBSD dovecot2 port maintainer to add it to the FreeBSD port instead?

I wouldn't mind them adding it.

I just saw it (~1500 users affected, dovecot disappeared)

dovecot: master: Panic: kevent() failed: Invalid argument

FreeBSD 11-RELEASE-p10, dovecot 2.2.29 (.1_2 package revision)

This thread was the only exact match on search engines…

No other match in last 60 days's logs of our two dovecot 'backends' (nor in last 10 years from my head)

Not sure if this can help… a least for stats …

@Timo: kudos for ~15 years of not experiencing this kind of bugs :)

*geoffroy desvernay* C.R.I - Administration systèmes et réseaux Ecole Centrale de Marseille

On 9 Jun 2017, at 16.29, geoffroy desvernay dgeo@centrale-marseille.fr wrote:

dovecot: master: Panic: kevent() failed: Invalid argument

 [EINVAL]		The specified time limit or filter is invalid.

Because this was the main kevent() call, I think it means that the time limit was invalid. But I wonder what exactly that means. Is it too low or too high? Do you have a core dump you could debug? Would be interesting to see what the value of "ts" is. Or you could try adding the attached patch and if it happens again, it would log ts's value.