dovecot[3005756]: master: Warning: SIGHUP received - reloading configuration
A couple of users have complained of "not receiving emails", after the usual tests I found that the possible problem was dovecot, I found these on the logs:
[root@hostname: /var/log]# grep SIGHUP maillog
Sep 14 14:32:36 hostname dovecot[3005756]: master: Warning: SIGHUP received - reloading configuration
Sep 14 17:32:35 hostname dovecot[3005756]: master: Warning: SIGHUP received - reloading configuration
Sep 15 02:32:34 hostname dovecot[3005756]: master: Warning: SIGHUP received - reloading configuration
Sep 15 17:32:42 hostname dovecot[3005756]: master: Warning: SIGHUP received - reloading configuration
Sep 15 23:32:46 hostname dovecot[3005756]: master: Warning: SIGHUP received - reloading configuration
Sep 16 17:32:43 hostname dovecot[3005756]: master: Warning: SIGHUP received - reloading configuration
Sep 16 23:33:07 hostname dovecot[3005756]: master: Warning: SIGHUP received - reloading configuration
Sep 17 02:32:42 hostname dovecot[3005756]: master: Warning: SIGHUP received - reloading configuration
Sep 17 17:32:48 hostname dovecot[3005756]: master: Warning: SIGHUP received - reloading configuration
Sep 18 02:32:46 hostname dovecot[3005756]: master: Warning: SIGHUP received - reloading configuration
After a little digging it turns out that apparently these signals are sent by some log rotation process, that's all fine so far since apparently SIGHUP signal is to reload configuration without reloading the whole service. However, right after every one of these signals each and every one of the user connections are terminated.
Here is a sample log entry for a single user, but there are dozens of these after each SIGHUP:
Sep 18 02:32:47 hostname dovecot[3706164]: imap(user@domain.com.com)<3909072><7eazRw4/isq920JE>: Disconnected: Server shutting down. in=1309, out=5153, bytes=1309/5153
This is my main suspect for these user complaints, maybe a user gets forcibly disconnected mid message download and the client struggles to connect again (the user reports that a client reload usually works)
I see two alternatives to try to solve this:
Is there a way to avoid disconnecting clients while the configuration is reloading? Apparently dovecot has a directive for that: shutdown_clients, any experience with this option?
And two: is there a way to make these logs rotate only in the middle of the night? Check the logs, most of the time they are rotating at the same times, this indicates a cron job is executing them.
I tried to find the way these log rotations are executed, I dug deep on the cpanel configurations and for the life of me could not find anything.
-
Hey there! There's several reasons this could be happening besides log rotation, and one of the most interesting things is that most of them seem to happen at 2:32 and 17:32, which some other more random restarts in there.
That leads me to believe a specific task is running at that time causing the issue.
Would you be able to monitor the server during that period to see if you can detect anything out of the ordinary on the system happening then?
0 -
This issue is causing bigger problems every time, these are still occurring at 17:32 every 48 hours more or less, tracing back I found these:
[root@host: /usr/local/cpanel/logs]# tail splitlogs_log
[2026-03-06 17:32:51] info: Clean shutdown of splitlogs (EOF+SIGTERM).
[2026-03-06 17:32:51] info: Clean shutdown of splitlogs (EOF+SIGTERM).
[2026-03-06 17:32:51] info: Begin splitlog processing
[2026-03-06 17:32:51] info: Clean shutdown of splitlogs (EOF+SIGTERM).
[2026-03-06 17:32:51] info: Begin splitlog processing
[2026-03-06 17:32:51] info: Begin splitlog processingIs there a way to change the time these occur? there is nothing in the crontab running at that time, if they have to run I need them to run at midnight, not at peak usage hour...
0 -
Since this issue has been going on for five months (at least) I would recommend submitting a ticket so this can be analyzed directly on the machine.
0 -
If you landed here from a google search:
AutoSSL, yes, you heard that right, AutoSSL.
This service apparently runs at minute 32 every three hours.[root@host: ~]# cat /etc/cron.d/cpanel_autossl
32 2,5,8,11,14,17,20,23 * * * root /usr/local/cpanel/bin/autossl_check --allI'm not sure (and honestly don't care that much) about the exact mechanism AutoSSL uses to reload the Dovecot configuration, but all the timestamps coincide. Every single one of them.
My best guess is that AutoSSL runs and, most of the time, comes back with no new certificates to install. However, when it does have a new certificate to install, it reloads the Dovecot (and other services') configuration so they can pick up the new certificate.
My fix was not to fight this. Instead, I simply configured Dovecot not to disconnect users during a graceful reload:
shutdown_clients = no
As of my installed version of cPanel (134.0.35) and Dovecot (2.4.2) the change was made in
/var/cpanel/conf/dovecot/main
So it survives cPanel upgrades and that kind stuff, just append the line to that file and then/usr/local/cpanel/scripts/builddovecotconf
And restart the serviceThat's what I did. A day later, I confirmed that another SIGHUP appeared in the logs, but this time none of the users were disconnected.I know is a tradeoff but having the users having to restart their clients for their email to work is worse.0 -
Thanks for the update!
It isn't interesting to me that a restart happens around the same time as AutoSSL work - as you've guessed, it needs to reload the certificate at some point.
What is interesting is that you're seeing email disruptions when this happens when I don't have any other reports of this behavior causing issues.
Are you able to create a ticket so this can be investigated directly on your system?
0
Please sign in to leave a comment.
Comments
5 comments