Am 18.01.20 um 23:14 schrieb Mark Sapiro:
On 1/18/20 6:13 AM, Torge Riedel wrote:
So now back to good. I checked all the logs prior to restarting the service in directory /opt/mailman/var/log, but I do not see any errors. And the master was still running, I would expect that the master will start / restart a runner in case it died?
What's in /opt/mailman/var/log/mailman.log? There should be entries like
Jan 18 13:51:11 2020 (11700) xxxx runner started.
for each runner every time it starts and like
Jan 18 13:47:31 2020 (10096) xxxx runner caught SIGTERM. Stopping. Jan 18 13:47:31 2020 (10096) xxxx runner exiting.
for each runner every time it stops, but with perhaps a reason other than
caught SIGTERM
That should at least tell you when they stopped. Also, if they stopped for some reason. The master will only restart runners that exit if they exit because of SIGUSR1 or some internal error and even then, only the configured max_restarts number of times.
Do you have a logrotate script for the logs in /opt/mailman/var/log, and if so, does it have a postrotate script that signals Mailman to reopen logs other than by a
mailman reopen
command, perhaps by signaling the master with other than SIGHUP?
Hi Mark,
I checked the logs for such entries and I do only see them when the logrotation runs and from yesterday where I restarted the service by myself.
So - yes, I have logrotation configured. The logrotation has a postrotate script configured which executes systemctl reload mailman
and I see in the logs, that it handles SIGUSR1. This happens daily in the morning and runs - for what I see - without any problems.
If I understand you right I should change it to "reopen" instead of "reload". I think this is something I have to pass to mailman executable itself instead to systemctl, right?
Best regards Torge