-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
configurable abort on fatal errors #4943
Conversation
2b4ae28
to
1c9ad1c
Compare
5ac6f9a
to
ed5d2b9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not seem to produce a core dump for failed assertions. Is that on purpose?
It ought to, Where are you seeing it not dump core? Perhaps I should add a test for assertion failures too. |
Sorry, my error. I must have overlooked the changes in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great, thanks for moving it from a local patch to a useful configurable option.
When a Cyrus process detects a fatal error, it logs an error message and shuts down with a non-zero exit code. This PR adds a new imapd.conf option
fatals_abort
, which when enabled, will cause Cyrus to callabort()
instead of exiting non-zero. Depending on system configuration, this will usually result in a core dump.Fastmail:
This will conflict with the "Fastmail ONLY - make assertion failures and fatal errors into coredumps" commit on our capstone branch. To deploy this change at Fastmail, I think we need to do something like:
fatals_abort: yes
. We start getting core dumps on fatal errors again.If we deploy the imapd.conf update before our Cyrus builds include this PR, we might get errors about the unrecognised option. So I think it's better to get the code deployed first, and then turn it on afterwards, though this leaves a window where we won't get core dumps.
We should not land this PR on the master branch until our own deployment process is finished, so that we can use include-in-fastmail to control the timing.