Sometimes when I reboot the machine, I experience that mailman doesn't
start because the files /opt/mailman3/mm/var/locks/master.lck* isn't
deleted during shutdown. Maybe one way to solve this could be to use
ExecStartPre directive in the systemd service to remove the lock files.
What's the best practice to solve this problem? BTW I've noticed that
doing systemctl stop mailman3 takes a very long time, 45 secs. or
something like that.
Mailman 3.3.10
Python 3.12.13
[Unit]
Description=GNU Mailing List Manager
After=syslog.target network.target postgresql.service
[Service]
Type=forking
PIDFile=/opt/mailman3/mm/var/master.pid
User=mailman3
Group=mailman3
Environment="MAILMAN_CONFIG_FILE=/etc/mailman3/mailman.cfg"
ExecStart=/opt/mailman3/venv/bin/mailman start
ExecReload=/opt/mailman3/venv/bin/mailman restart
ExecStop=/opt/mailman3/venv/bin/mailman stop
# Tested, but have no effect on deletion of the lock file.
#Restart=on-failure
#RestartSec=15
[Install]
WantedBy=multi-user.target
Lars
On 6/21/26 4:16 AM, Lars Bjørndal wrote:
Sometimes when I reboot the machine, I experience that mailman doesn't start because the files /opt/mailman3/mm/var/locks/master.lck* isn't deleted during shutdown. Maybe one way to solve this could be to use ExecStartPre directive in the systemd service to remove the lock files. What's the best practice to solve this problem?
You can add --force to the ExecStart command in your service file.
BTW I've noticed that doing
systemctl stop mailman3takes a very long time, 45 secs. or something like that.
This is because it waits for all the runners to exit and bounce runner in particular sleeps for (default) 15 seconds.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 6/21/26 8:50 AM, Mark Sapiro wrote:
This is because it waits for all the runners to exit and bounce runner in particular sleeps for (default) 15 seconds.
Actually, the default sleep time for the bounce runner is 2 minutes, and the retry runner sleeps even longer <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/config/mailman....>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thank you! You wrote:
On 6/21/26 4:16 AM, Lars Bjørndal wrote:
Sometimes when I reboot the machine, I experience that mailman doesn't start because the files /opt/mailman3/mm/var/locks/master.lck* isn't deleted during shutdown. Maybe one way to solve this could be to use ExecStartPre directive in the systemd service to remove the lock files. What's the best practice to solve this problem?
You can add
--forceto theExecStartcommand in your service file.
At least, with the --force option, Mailman started successfully this morning when I rebooted the machine.
[...]
Lars
Le 2026-06-21 11:16, Lars Bjørndal a écrit :
Sometimes when I reboot the machine, I experience that mailman doesn't start because the files /opt/mailman3/mm/var/locks/master.lck* isn't deleted during shutdown. Maybe one way to solve this could be to use ExecStartPre directive in the systemd service to remove the lock files. What's the best practice to solve this problem? BTW I've noticed that doing
systemctl stop mailman3takes a very long time, 45 secs. or something like that.
How about this ...
rm /opt/mailman/mm/var/locks/* systemctl start mailman3 systemctl start mailmanweb systemctl daemon-reload systemctl start qcluster
What is in the logs about why the locks remain? There should be something in the system log about it if systemd kills a service process because it doesn't stop in time during shutdown... -Gerald
On 21.06.26 13:16, Lars Bjørndal wrote:
Sometimes when I reboot the machine, I experience that mailman doesn't start because the files /opt/mailman3/mm/var/locks/master.lck* isn't deleted during shutdown. Maybe one way to solve this could be to use ExecStartPre directive in the systemd service to remove the lock files. What's the best practice to solve this problem? BTW I've noticed that doing
systemctl stop mailman3takes a very long time, 45 secs. or something like that.
Mailman 3.3.10
Python 3.12.13
[Unit] Description=GNU Mailing List Manager After=syslog.target network.target postgresql.service [Service] Type=forking PIDFile=/opt/mailman3/mm/var/master.pid User=mailman3 Group=mailman3 Environment="MAILMAN_CONFIG_FILE=/etc/mailman3/mailman.cfg" ExecStart=/opt/mailman3/venv/bin/mailman start ExecReload=/opt/mailman3/venv/bin/mailman restart ExecStop=/opt/mailman3/venv/bin/mailman stop # Tested, but have no effect on deletion of the lock file. #Restart=on-failure #RestartSec=15 [Install] WantedBy=multi-user.targetLars
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to vogt@spamcop.net
[Gerald]
What is in the logs about why the locks remain? There should be something in the system log about it if systemd kills a service process because it doesn't stop in time during shutdown... -Gerald
I got this:
juni 12 08:13:28 dalen.lamasti.net systemd[1]: Stopping mailman3.service - GNU Mailing List Manager...
juni 12 08:13:49 dalen.lamasti.net mailman[497907]: Shutting down Mailman's master runner
juni 12 08:13:51 dalen.lamasti.net mailman[1851]: Traceback (most recent call last):
juni 12 08:13:51 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1363, in main
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: Traceback (most recent call last):
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: rv = self.invoke(ctx)
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: Traceback (most recent call last):
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1226, in invoke
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return ctx.invoke(self.callback, **ctx.params)
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return callback(*args, **kwargs)
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return f(get_current_context(), *args, **kwargs)
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: sys.exit(runner.status)
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: SystemExit: 15
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: During handling of the above exception, another exception occurred:
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: Traceback (most recent call last):
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/bin/runner", line 8, in <module>
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: sys.exit(main())
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: return callback(*args, **kwargs)
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1442, in __call__
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return self.main(*args, **kwargs)
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1362, in main
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: with self.make_context(prog_name, args, **extra) as ctx:
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 480, in __exit__
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: def __exit__(
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/core/runner.py", line 117, in signal_handler
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: ^^^^^^^^^^^^^^^^^^^^^^^^^
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: return callback(*args, **kwargs)
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: ^^^^^^^^^^^^^^^^^^^^^^^^^
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: return f(get_current_context(), *args, **kwargs)
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: return f(get_current_context(), *args, **kwargs)
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: sys.exit(runner.status)
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: sys.exit(runner.status)
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: SystemExit: 15
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: During handling of the above exception, another exception occurred:
...
Lars
On 21.06.26 13:16, Lars Bjørndal wrote:
Sometimes when I reboot the machine, I experience that mailman doesn't start because the files /opt/mailman3/mm/var/locks/master.lck* isn't deleted during shutdown. Maybe one way to solve this could be to use ExecStartPre directive in the systemd service to remove the lock files. What's the best practice to solve this problem? BTW I've noticed that doing
systemctl stop mailman3takes a very long time, 45 secs. or something like that.
Mailman 3.3.10
Python 3.12.13
[Unit] Description=GNU Mailing List Manager After=syslog.target network.target postgresql.service [Service] Type=forking PIDFile=/opt/mailman3/mm/var/master.pid User=mailman3 Group=mailman3 Environment="MAILMAN_CONFIG_FILE=/etc/mailman3/mailman.cfg" ExecStart=/opt/mailman3/venv/bin/mailman start ExecReload=/opt/mailman3/venv/bin/mailman restart ExecStop=/opt/mailman3/venv/bin/mailman stop # Tested, but have no effect on deletion of the lock file. #Restart=on-failure #RestartSec=15 [Install] WantedBy=multi-user.targetLars
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to vogt@spamcop.net
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to lars@lamasti.net
Well, then fixing this exception would be the solution to your problem. Discarding the lock files or using the force option doesn't solve the real problem. -Gerald
On 22.06.26 08:56, Lars Bjørndal wrote:
[Gerald]
What is in the logs about why the locks remain? There should be something in the system log about it if systemd kills a service process because it doesn't stop in time during shutdown... -Gerald
I got this:
juni 12 08:13:28 dalen.lamasti.net systemd[1]: Stopping mailman3.service - GNU Mailing List Manager... juni 12 08:13:49 dalen.lamasti.net mailman[497907]: Shutting down Mailman's master runner juni 12 08:13:51 dalen.lamasti.net mailman[1851]: Traceback (most recent call last): juni 12 08:13:51 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1363, in main juni 12 08:13:52 dalen.lamasti.net mailman[1855]: Traceback (most recent call last): juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1851]: rv = self.invoke(ctx) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1860]: Traceback (most recent call last): juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1226, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return ctx.invoke(self.callback, **ctx.params) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1851]: sys.exit(runner.status) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: SystemExit: 15 juni 12 08:13:52 dalen.lamasti.net mailman[1851]: During handling of the above exception, another exception occurred: juni 12 08:13:52 dalen.lamasti.net mailman[1851]: Traceback (most recent call last): juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/bin/runner", line 8, in <module> juni 12 08:13:52 dalen.lamasti.net mailman[1851]: sys.exit(main()) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1855]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1442, in __call__ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return self.main(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1362, in main juni 12 08:13:52 dalen.lamasti.net mailman[1851]: with self.make_context(prog_name, args, **extra) as ctx: juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 480, in __exit__ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: def __exit__( juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/core/runner.py", line 117, in signal_handler juni 12 08:13:52 dalen.lamasti.net mailman[1855]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1860]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1860]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1860]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1855]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1860]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1860]: sys.exit(runner.status) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1855]: sys.exit(runner.status) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: SystemExit: 15 juni 12 08:13:52 dalen.lamasti.net mailman[1855]: During handling of the above exception, another exception occurred: ...Lars
On 21.06.26 13:16, Lars Bjørndal wrote:
Sometimes when I reboot the machine, I experience that mailman doesn't start because the files /opt/mailman3/mm/var/locks/master.lck* isn't deleted during shutdown. Maybe one way to solve this could be to use ExecStartPre directive in the systemd service to remove the lock files. What's the best practice to solve this problem? BTW I've noticed that doing
systemctl stop mailman3takes a very long time, 45 secs. or something like that.
Mailman 3.3.10
Python 3.12.13
[Unit] Description=GNU Mailing List Manager After=syslog.target network.target postgresql.service [Service] Type=forking PIDFile=/opt/mailman3/mm/var/master.pid User=mailman3 Group=mailman3 Environment="MAILMAN_CONFIG_FILE=/etc/mailman3/mailman.cfg" ExecStart=/opt/mailman3/venv/bin/mailman start ExecReload=/opt/mailman3/venv/bin/mailman restart ExecStop=/opt/mailman3/venv/bin/mailman stop # Tested, but have no effect on deletion of the lock file. #Restart=on-failure #RestartSec=15 [Install] WantedBy=multi-user.targetLars
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to vogt@spamcop.net
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to lars@lamasti.net
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to vogt@spamcop.net
Thank you, Gerald! You wrote:
Well, then fixing this exception would be the solution to your problem. Discarding the lock files or using the force option doesn't solve the real problem. -Gerald
That sounds reasonable. Do you have any hint on why this exception happens now and then when rebooting?
Thanks, Lars
Lars Bjørndal writes:
[Gerald]
What is in the logs about why the locks remain? There should be something in the system log about it if systemd kills a service process because it doesn't stop in time during shutdown... -Gerald
I got this:
It's hard to say what's happening because your traceback(s) are truncated. The fact that the timestamps are all the same suggests that the problem isn't that systemd gets tired of waiting and eventually force-kills (signal 9) Mailman. Rather, systemd times out because Mailman aborts from an internal Exception (not in the log you reported) and never removes the pidfile, so systemd doesn't know that Mailman exited. The locks remain because Mailman aborted.
Normally you don't clean up locks because you don't want whatever happened to destroy even more data, but experience has shown that these events "never" (as far as we know) destroy data. The store-and-forward discipline for the message-handling queues is very robust. I would say it's nearly mathematically certain that Mailman exceptions cannot destroy messages. Apparently we get the granularity of database transactions right, but I'm not as sure of that.
I'm guessing that all of the runners eventually raise the same exception, but the first mention is likely to be quite a way down in the log file.
We need to see the tracebacks all the way to the end or we can't help. It's likely to be *very* long if all 15 or so runners raise the exception.
For the terminally curious, a few comments are below the lines being analyzed. Since the timestamps are all the same, I'm going to collect the logs for each process for clarity.
juni 12 08:13:28 dalen.lamasti.net systemd[1]: Stopping mailman3.service - GNU Mailing List Manager... juni 12 08:13:49 dalen.lamasti.net mailman[497907]: Shutting down Mailman's master runner
This process is the mailman command line utility to shut down the Mailman
system. (Mailman appears to have run quite a while before being stopped.)
juni 12 08:13:51 dalen.lamasti.net mailman[1851]: Traceback (most recent call last):
This appears to be a runner process (queue handling worker), forked from the master process mentioned above. But it might be the master itself. This is probably in the boot process for the OS, invoked automatically by init (systemd).
juni 12 08:13:51 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1363, in main juni 12 08:13:52 dalen.lamasti.net mailman[1851]: rv = self.invoke(ctx) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1226, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return ctx.invoke(self.callback, **ctx.params) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1851]: sys.exit(runner.status) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: SystemExit: 15
This is a "shut down gracefully" signal received presumably from the master runner process. This looks normal.
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: During handling of the above exception, another exception occurred:
"Above exception" == SystemExit, raised when receiving the "shut down" signal.
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: Traceback (most recent call last): juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/bin/runner", line 8, in <module> juni 12 08:13:52 dalen.lamasti.net mailman[1851]: sys.exit(main()) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1442, in __call__ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return self.main(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1362, in main juni 12 08:13:52 dalen.lamasti.net mailman[1851]: with self.make_context(prog_name, args, **extra) as ctx: juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 480, in __exit__ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: def __exit__( juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/core/runner.py", line 117, in signal_handler
This is not the end of the log for this process, the line of code should be quoted later in the log, and probably the log continues.
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: Traceback (most recent call last):
Another runner process. Note that the traceback is the same as the traceback for process 1851, as far as it goes.
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1855]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1855]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1855]: sys.exit(runner.status) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: SystemExit: 15 juni 12 08:13:52 dalen.lamasti.net mailman[1855]: During handling of the above exception, another exception occurred:
Again, the log is truncated for this process.
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: Traceback (most recent call last):
Another runner process. Note that the traceback is the same as the traceback for process 1851, as far as it goes.
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1860]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1860]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1860]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1860]: sys.exit(runner.status)
The exception is almost certainly another SystemExit. It looks like all of the runners are going to have the same logs, interleaved.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Thank you, Stephen! Your information is interesting. I think, next time it happens, even though I now use the --force to the start command, I will post the complete log.
Thanks, Lars
On Tue, Jun 23, 2026 at 01:31:23AM +0900, Stephen J. Turnbull wrote:
Lars Bjørndal writes:
[Gerald]
What is in the logs about why the locks remain? There should be something in the system log about it if systemd kills a service process because it doesn't stop in time during shutdown... -Gerald
I got this:
It's hard to say what's happening because your traceback(s) are truncated. The fact that the timestamps are all the same suggests that the problem isn't that systemd gets tired of waiting and eventually force-kills (signal 9) Mailman. Rather, systemd times out because Mailman aborts from an internal Exception (not in the log you reported) and never removes the pidfile, so systemd doesn't know that Mailman exited. The locks remain because Mailman aborted.
Normally you don't clean up locks because you don't want whatever happened to destroy even more data, but experience has shown that these events "never" (as far as we know) destroy data. The store-and-forward discipline for the message-handling queues is very robust. I would say it's nearly mathematically certain that Mailman exceptions cannot destroy messages. Apparently we get the granularity of database transactions right, but I'm not as sure of that.
I'm guessing that all of the runners eventually raise the same exception, but the first mention is likely to be quite a way down in the log file.
We need to see the tracebacks all the way to the end or we can't help. It's likely to be *very* long if all 15 or so runners raise the exception.
For the terminally curious, a few comments are below the lines being analyzed. Since the timestamps are all the same, I'm going to collect the logs for each process for clarity.
juni 12 08:13:28 dalen.lamasti.net systemd[1]: Stopping mailman3.service - GNU Mailing List Manager... juni 12 08:13:49 dalen.lamasti.net mailman[497907]: Shutting down Mailman's master runner
This process is the
mailmancommand line utility to shut down the Mailman system. (Mailman appears to have run quite a while before being stopped.)juni 12 08:13:51 dalen.lamasti.net mailman[1851]: Traceback (most recent call last):
This appears to be a runner process (queue handling worker), forked from the master process mentioned above. But it might be the master itself. This is probably in the boot process for the OS, invoked automatically by init (systemd).
juni 12 08:13:51 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1363, in main juni 12 08:13:52 dalen.lamasti.net mailman[1851]: rv = self.invoke(ctx) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1226, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return ctx.invoke(self.callback, **ctx.params) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1851]: sys.exit(runner.status) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: SystemExit: 15
This is a "shut down gracefully" signal received presumably from the master runner process. This looks normal.
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: During handling of the above exception, another exception occurred:
"Above exception" == SystemExit, raised when receiving the "shut down" signal.
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: Traceback (most recent call last): juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/bin/runner", line 8, in <module> juni 12 08:13:52 dalen.lamasti.net mailman[1851]: sys.exit(main()) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1442, in __call__ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return self.main(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1362, in main juni 12 08:13:52 dalen.lamasti.net mailman[1851]: with self.make_context(prog_name, args, **extra) as ctx: juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 480, in __exit__ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: def __exit__( juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/core/runner.py", line 117, in signal_handler
This is not the end of the log for this process, the line of code should be quoted later in the log, and probably the log continues.
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: Traceback (most recent call last):
Another runner process. Note that the traceback is the same as the traceback for process 1851, as far as it goes.
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1855]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1855]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1855]: sys.exit(runner.status) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: SystemExit: 15 juni 12 08:13:52 dalen.lamasti.net mailman[1855]: During handling of the above exception, another exception occurred:
Again, the log is truncated for this process.
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: Traceback (most recent call last):
Another runner process. Note that the traceback is the same as the traceback for process 1851, as far as it goes.
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1860]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1860]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1860]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1860]: sys.exit(runner.status)
The exception is almost certainly another SystemExit. It looks like all of the runners are going to have the same logs, interleaved.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Replying to myself:
On Mon, Jun 22, 2026 at 07:34:36PM +0200, Lars Bjørndal wrote:
Thank you, Stephen! Your information is interesting. I think, next time it happens, even though I now use the --force to the start command, I will post the complete log.
Here is the log after a newly emerged problem when rebooting, where I had to manually start mailman3. The first 65 lines has to do with shutdonw, and the rest has to do with system startup. The log is huge, so I put it here:
https://lamasti.net/filer/shutdown.log.gz
All tips on how to get rid of these problems are welcome.
Thanks, Lars
On Tue, Jun 23, 2026 at 01:31:23AM +0900, Stephen J. Turnbull wrote:
Lars Bjørndal writes:
[Gerald]
What is in the logs about why the locks remain? There should be something in the system log about it if systemd kills a service process because it doesn't stop in time during shutdown... -Gerald
I got this:
It's hard to say what's happening because your traceback(s) are truncated. The fact that the timestamps are all the same suggests that the problem isn't that systemd gets tired of waiting and eventually force-kills (signal 9) Mailman. Rather, systemd times out because Mailman aborts from an internal Exception (not in the log you reported) and never removes the pidfile, so systemd doesn't know that Mailman exited. The locks remain because Mailman aborted.
Normally you don't clean up locks because you don't want whatever happened to destroy even more data, but experience has shown that these events "never" (as far as we know) destroy data. The store-and-forward discipline for the message-handling queues is very robust. I would say it's nearly mathematically certain that Mailman exceptions cannot destroy messages. Apparently we get the granularity of database transactions right, but I'm not as sure of that.
I'm guessing that all of the runners eventually raise the same exception, but the first mention is likely to be quite a way down in the log file.
We need to see the tracebacks all the way to the end or we can't help. It's likely to be *very* long if all 15 or so runners raise the exception.
For the terminally curious, a few comments are below the lines being analyzed. Since the timestamps are all the same, I'm going to collect the logs for each process for clarity.
juni 12 08:13:28 dalen.lamasti.net systemd[1]: Stopping mailman3.service - GNU Mailing List Manager... juni 12 08:13:49 dalen.lamasti.net mailman[497907]: Shutting down Mailman's master runner
This process is the
mailmancommand line utility to shut down the Mailman system. (Mailman appears to have run quite a while before being stopped.)juni 12 08:13:51 dalen.lamasti.net mailman[1851]: Traceback (most recent call last):
This appears to be a runner process (queue handling worker), forked from the master process mentioned above. But it might be the master itself. This is probably in the boot process for the OS, invoked automatically by init (systemd).
juni 12 08:13:51 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1363, in main juni 12 08:13:52 dalen.lamasti.net mailman[1851]: rv = self.invoke(ctx) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1226, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return ctx.invoke(self.callback, **ctx.params) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1851]: sys.exit(runner.status) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: SystemExit: 15
This is a "shut down gracefully" signal received presumably from the master runner process. This looks normal.
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: During handling of the above exception, another exception occurred:
"Above exception" == SystemExit, raised when receiving the "shut down" signal.
juni 12 08:13:52 dalen.lamasti.net mailman[1851]: Traceback (most recent call last): juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/bin/runner", line 8, in <module> juni 12 08:13:52 dalen.lamasti.net mailman[1851]: sys.exit(main()) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1442, in __call__ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: return self.main(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 1362, in main juni 12 08:13:52 dalen.lamasti.net mailman[1851]: with self.make_context(prog_name, args, **extra) as ctx: juni 12 08:13:52 dalen.lamasti.net mailman[1851]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 480, in __exit__ juni 12 08:13:52 dalen.lamasti.net mailman[1851]: def __exit__( juni 12 08:13:52 dalen.lamasti.net mailman[1851]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/core/runner.py", line 117, in signal_handler
This is not the end of the log for this process, the line of code should be quoted later in the log, and probably the log continues.
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: Traceback (most recent call last):
Another runner process. Note that the traceback is the same as the traceback for process 1851, as far as it goes.
juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke juni 12 08:13:52 dalen.lamasti.net mailman[1855]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1855]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1855]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1855]: sys.exit(runner.status) juni 12 08:13:52 dalen.lamasti.net mailman[1855]: SystemExit: 15 juni 12 08:13:52 dalen.lamasti.net mailman[1855]: During handling of the above exception, another exception occurred:
Again, the log is truncated for this process.
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: Traceback (most recent call last):
Another runner process. Note that the traceback is the same as the traceback for process 1851, as far as it goes.
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/core.py", line 794, in invoke
juni 12 08:13:52 dalen.lamasti.net mailman[1860]: return callback(*args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1860]: ^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/click/decorators.py", line 34, in new_func juni 12 08:13:52 dalen.lamasti.net mailman[1860]: return f(get_current_context(), *args, **kwargs) juni 12 08:13:52 dalen.lamasti.net mailman[1860]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ juni 12 08:13:52 dalen.lamasti.net mailman[1860]: File "/opt/mailman3/venv/lib64/python3.12/site-packages/mailman/bin/runner.py", line 198, in main juni 12 08:13:52 dalen.lamasti.net mailman[1860]: sys.exit(runner.status)
The exception is almost certainly another SystemExit. It looks like all of the runners are going to have the same logs, interleaved.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to lars@lamasti.net
Lars Bjørndal writes:
You've got some kind of logging problem with writing to the persistent storage for the log, whatever that is (defaults to several files in $var/dir/logs, but can be configured very flexibly using the stdlib logging module). A bunch of Mailman processes are raising exceptions when trying to log that they're shutting down. This could result in a deadlock, which is why systemd terminates the processes with SIGABRT.
There's also a message about reentrancy (I think only one per process, but Mailman 3 spawns lots of processes). It might be a bug in logging (not Mailman code) but I think that's some exception handler that's trying to log the logging exception. If so, it's not the root problem and should not recur if you fix the basic problem.
- What, if anything, is in Mailman's own logs? This appears to be systemd's log from journalctl.
- Do you have any settings for logging in mailman.cfg?
- If your logging handler is a file-based handler, maybe the log partition is full.
- Maybe there is some security restriction (selinux?) on the logging channel, whatever it is. Or a permissions restriction on the file system so Mailman can't write.
I also noticed that PostgreSQL gets shut down, but there's no log that it gets restarted. I think Mailman should then shutdown with an error that it can't talk to the database, but maybe it retries a few times.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Thanks a lot for your input!
You wrote:
Lars Bjørndal writes:
You've got some kind of logging problem with writing to the persistent storage for the log, whatever that is (defaults to several files in $var/dir/logs, but can be configured very flexibly using the stdlib logging module).
I've installed mailman3 following the guide at https://docs.mailman3.org/en/latest/install/virtualenv.html. So Mailma's log files is in /opt/mailman3/mm/var/log. But the log I've provided, is, as you say, from systemd/journalctl.
A bunch of Mailman processes are raising exceptions when trying to log that they're shutting down. This could result in a deadlock, which is why systemd terminates the processes with SIGABRT.
There's also a message about reentrancy (I think only one per process, but Mailman 3 spawns lots of processes). It might be a bug in logging (not Mailman code) but I think that's some exception handler that's trying to log the logging exception. If so, it's not the root problem and should not recur if you fix the basic problem.
- What, if anything, is in Mailman's own logs? This appears to be systemd's log from journalctl.
In /opt/mailman3/mm/var/logs/error.log I have:
[2026-07-20 08:57:39 +0200] [2594] [INFO] Handling signal: int
[2026-07-20 08:57:41 +0200] [2594] [ERROR] Worker (pid:2596) was sent code 131!
[2026-07-20 08:57:42 +0200] [2594] [INFO] Shutting down: Master
[2026-07-20 09:02:00 +0200] [2510] [INFO] Starting gunicorn 23.0.0
[2026-07-20 09:02:00 +0200] [2510] [INFO] Listening at: http://127.0.0.1:8000 (2510)
[2026-07-20 09:02:00 +0200] [2510] [INFO] Using worker: sync
[2026-07-20 09:02:00 +0200] [2538] [INFO] Booting worker with pid: 2538
- Do you have any settings for logging in mailman.cfg?
No, nothing.
- If your logging handler is a file-based handler, maybe the log partition is full.
Both /opt and /var is on the same file system with lot of space.
- Maybe there is some security restriction (selinux?) on the logging channel, whatever it is. Or a permissions restriction on the file system so Mailman can't write.
I don't think so, because Mailman writes to it's logs in /opt/mailman3/mm/var/log. I don't use selinux.
I also noticed that PostgreSQL gets shut down, but there's no log that it gets restarted. I think Mailman should then shutdown with an error that it can't talk to the database, but maybe it retries a few times.
From the log I can see that PostgeSQL is started before mailman tries to start.
Lars
On Tuesday, 21 July 2026 22:53:59 CEST Lars Bjørndal wrote:
Thanks a lot for your input!
You wrote:
Lars Bjørndal writes:
You've got some kind of logging problem with writing to the persistent storage for the log, whatever that is (defaults to several files in $var/dir/logs, but can be configured very flexibly using the stdlib logging module).
I've installed mailman3 following the guide at https://docs.mailman3.org/en/latest/install/virtualenv.html. So Mailma's log files is in /opt/mailman3/mm/var/log. But the log I've provided, is, as you say, from systemd/journalctl.
A bunch of Mailman processes are raising exceptions when trying to log that they're shutting down. This could result in a deadlock, which is why systemd terminates the processes with SIGABRT.
There's also a message about reentrancy (I think only one per process, but Mailman 3 spawns lots of processes). It might be a bug in logging (not Mailman code) but I think that's some exception handler that's trying to log the logging exception. If so, it's not the root problem and should not recur if you fix the basic problem.
What, if anything, is in Mailman's own logs? This appears to be
systemd's log from journalctl.
In /opt/mailman3/mm/var/logs/error.log I have:
[2026-07-20 08:57:39 +0200] [2594] [INFO] Handling signal: int [2026-07-20 08:57:41 +0200] [2594] [ERROR] Worker (pid:2596) was sent code 131! [2026-07-20 08:57:42 +0200] [2594] [INFO] Shutting down: Master [2026-07-20 09:02:00 +0200] [2510] [INFO] Starting gunicorn 23.0.0 [2026-07-20 09:02:00 +0200] [2510] [INFO] Listening at: http://127.0.0.1:8000 (2510) [2026-07-20 09:02:00 +0200] [2510] [INFO] Using worker: sync [2026-07-20 09:02:00 +0200] [2538] [INFO] Booting worker with pid: 2538
- Do you have any settings for logging in mailman.cfg?
No, nothing.
If your logging handler is a file-based handler, maybe the log
partition is full.
Both /opt and /var is on the same file system with lot of space.
Maybe there is some security restriction (selinux?) on the logging
channel, whatever it is. Or a permissions restriction on the file system so Mailman can't write.
I don't think so, because Mailman writes to it's logs in /opt/mailman3/mm/var/log. I don't use selinux.
I also noticed that PostgreSQL gets shut down, but there's no log that it gets restarted. I think Mailman should then shutdown with an error that it can't talk to the database, but maybe it retries a few times.
From the log I can see that PostgeSQL is started before mailman tries to start.
Lars
Just two ideas:
Are you sure your mailman *.service files are correct. Especially with respect to ordering startup and shutdown (After= and things like that)? Does it contain your database service and network?
Are you sure your filesystem(s) with /opt and /var is/are still mounted when this happens? Don't know how you could check that. But they are local filesystems, no network involved?
Andreas
Hi, Andreas, and thank you for your suggestions. You wrote:
[...]
Are you sure your mailman *.service files are correct. Especially with respect to ordering startup and shutdown (After= and things like that)? Does it contain your database service and network?
Yes, the file has:
After=syslog.target network.target postgresql.service
> Are you sure your filesystem(s) with /opt and /var is/are still mounted when
> this happens? Don't know how you could check that. But they are local
> filesystems, no network involved?
Yes, they are on the one filesystem that are on this system other than boot and swap, that have their own filesystems. No network filesystem involved.
Thanks,
Lars
Lars Bjørndal writes:
Thanks a lot for your input!
You're welcome. Thank you for checking the additional information. Unfortunately it doesn't really help me. Maybe Mark or Abhilash has some idea. When I get time I'll try reading the code, but I don't think the bug/trigger is in the shutdown code where the exception gets raised, rather I expect it's in setup or operational code. So it may take a while to track it down.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Thank you. And please tell me if you need more information.
Lars
On Wed, Jul 22, 2026 at 11:08:30PM +0900, Stephen J. Turnbull wrote:
Lars Bjørndal writes:
Thanks a lot for your input!
You're welcome. Thank you for checking the additional information. Unfortunately it doesn't really help me. Maybe Mark or Abhilash has some idea. When I get time I'll try reading the code, but I don't think the bug/trigger is in the shutdown code where the exception gets raised, rather I expect it's in setup or operational code. So it may take a while to track it down.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
participants (6)
-
Andreas Vetter -
Gerald Vogt -
iMark -
Lars Bjørndal -
Mark Sapiro -
Stephen J. Turnbull