Again, after systemupgrade the log file in /var/log/mailman was owned by list:list instead of mailman:mailman and starting failed for this reason [support request]
I made for a repeated time (after system update and/or system reboot) the experience,that my mailman3 installation fails to start because of permission error to write the log file.
For some unknown reason, an empty file /var/og/mailman/mailman.log was apparently owned by list:list. I deleted that file and mailman3 core could now be started. The start problem i solved.
I asked myself and you, how can this happen for many times? Has anyone an idea what the reason could be?
There is still a user list from a previous mailman3 installation, where I assigned the (former user for mailman2), but I suppose the problem is a different problem than a simple user definition.
The other log files are always correctly assigned to mailman:mailman
<pre> -rw-rw---- 1 mailman mailman 7487 Dec 22 18:21 bounce.log 0 -rw-rw---- 1 mailman mailman 0 Oct 8 22:46 debug.log 4 -rw-rw---- 1 mailman mailman 1909 Dec 24 09:10 mailman.log 57448 -rw-rw---- 1 mailman mailman 58820418 Dec 24 09:00 mailman.log.1 108 -rw-rw---- 1 mailman mailman 108407 Oct 24 12:18 mailman.log.2.gz 0 -rw-rw---- 1 mailman mailman 0 Oct 8 22:46 plugins.log 232 -rw-rw---- 1 mailman mailman 229585 Dec 24 09:10 smtp.log 4 drwxr-xr-x 2 mailman mailman 4096 Oct 20 00:00 <font color="#729FCF"><b>web</b></font> </pre>
On Sun, Dec 24, 2023 at 12:21 PM Wikinaut <mail@tgries.de> wrote:
I made for a repeated time (after system update and/or system reboot) the experience,that my mailman3 installation fails to start because of permission error to write the log file.
For some unknown reason, an empty file /var/og/mailman/mailman.log was apparently owned by list:list. I deleted that file and mailman3 core could now be started. The start problem i solved.
I asked myself and you, how can this happen for many times? Has anyone an idea what the reason could be?
It can only mean that there is a process, running as list:list that created the file.
There is still a user list from a previous mailman3 installation, where I assigned the (former user for mailman2), but I suppose the problem is a different problem than a simple user definition.
In a virtualenv type of installation, such an issue does not arise as everything in the virtualenv is owned by mailman:mailman. So maybe you can consider migrating to a virtualenv install?
Check if you have something withing logrorate config that creates the file.It's a guess.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
I use virtualenv - strictly setup freshly as described in the mailman3-description.
The issue may be a relict stemming from the former installation, difficult to find.
Thanks for the points to consider. (will check logrotate, cleaned also all files in the /var/log/mailman before, when I saw the problem for the first or the second time. Now, it's about the fourth time it happened.)
On Sun, Dec 24, 2023 at 1:50 PM Wikinaut <mail@tgries.de> wrote:
I use virtualenv - strictly setup freshly as described in the mailman3-description.
The virtualenv type of installation should not be writing anything to /var/log/mailman. I meant this documentation: https://docs.list.org/en/latest/install/virtualenv.html#virtualenv-install Even if you did not use /opt/mailman/ as suggested in this documentation, the var_dir config in mailman.cfg should NOT point to /var/log!
# /etc/mailman3/mailman.cfg
[paths.here]
var_dir: /opt/mailman/mm/var
There is no way mailman would be logging to /var/log if you did setup that value to a path within the virtualenv. Plus, having mailman files in /var/log in itself would be scary. So I believe you aren't using the virtualenv method.
The issue may be a relict stemming from the former installation, difficult to find.
Use virtualenv and you will not be fighting this war.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
This is in
/opt/mailman/web/logs# dir total 3164 276 -rw-r--r-- 1 mailman mailman 274457 Dec 24 09:05 mailmanweb.log 2056 -rw-r----- 1 mailman mailman 2100388 Dec 24 09:05 uwsgi-error.log 832 -rw-r----- 1 mailman mailman 846536 Dec 24 09:10 uwsgi.log
Looks okay.
This is my /etc/systemd/system/mailman3.service:
Unit] Description=GNU Mailing List Manager After=syslog.target network.target mysql.service
[Service] Type=forking User=mailman Group=mailman PIDFile=/opt/mailman/venv/bin/master.pid ExecStart=/opt/mailman/venv/bin/mailman start --force ExecReload=/opt/mailman/venv/bin/mailman restart --force ExecStop=/opt/mailman/venv/bin/mailman stop
[Install] WantedBy=multi-user.target
This mailman3web.service:
[Unit] Description=GNU Mailman Web UI After=syslog.target network.target mysql.service mailman3.service
[Service] Environment="PYTHONPATH=/etc/mailman3/" User=mailman Group=mailman ExecStart=/opt/mailman/venv/bin/uwsgi --ini /etc/mailman3/uwsgi.ini KillSignal=SIGINT
[Install] WantedBy=multi-user.target
I do use the venv method, but the other issue may be a relict from former setup, as I said, and difficult to find. It so very strange, that the log-permisison issue stems from → systemctl start mailman3.
On Sun, Dec 24, 2023 at 3:35 PM Wikinaut <mail@tgries.de> wrote:
This is in
/opt/mailman/web/logs# dir total 3164 276 -rw-r--r-- 1 mailman mailman 274457 Dec 24 09:05 mailmanweb.log 2056 -rw-r----- 1 mailman mailman 2100388 Dec 24 09:05 uwsgi-error.log 832 -rw-r----- 1 mailman mailman 846536 Dec 24 09:10 uwsgi.log
Looks okay.
This is my /etc/systemd/system/mailman3.service:
Unit] Description=GNU Mailing List Manager After=syslog.target network.target mysql.service
[Service] Type=forking User=mailman Group=mailman PIDFile=/opt/mailman/venv/bin/master.pid ExecStart=/opt/mailman/venv/bin/mailman start --force ExecReload=/opt/mailman/venv/bin/mailman restart --force ExecStop=/opt/mailman/venv/bin/mailman stop
[Install] WantedBy=multi-user.target
This mailman3web.service:
[Unit] Description=GNU Mailman Web UI After=syslog.target network.target mysql.service mailman3.service
[Service] Environment="PYTHONPATH=/etc/mailman3/" User=mailman Group=mailman ExecStart=/opt/mailman/venv/bin/uwsgi --ini /etc/mailman3/uwsgi.ini KillSignal=SIGINT
[Install] WantedBy=multi-user.target
I do use the venv method, but the other issue may be a relict from former setup, as I said, and difficult to find. It so very strange, that the log-permisison issue stems from → systemctl start mailman3.
Because you were referring to /var/log/, can you please share the output of the following:
grep var_dir /etc/mailman3/mailman.cfg
In my mailman.cfg, I have: var_dir: /opt/mailman/mm/var And in my settings.py I have /opt/mailman/mm/var/logs/mailmanweb.log specified for mailman-web. As you can see, mailman core and mailman-web both log to /opt/mailman/mm/var and given that /opt/mailman is owned by mailman:mailman, I don't see how a file owned by list:list would appear there. I also don't see how anything to do with /var/log/ is in your vocabulary :-)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
Here is the output:
grep var_dir /etc/mailman3/mailman.cfg
# can be as simple as $var_dir/history.py to put the file in the var directory. # be different from a FHS layout. Most paths are based off the var_dir, and var_dir: /var/lib/mailman3 queue_dir: $var_dir/queue list_data_dir: $var_dir/lists lock_dir: $var_dir/locks data_dir: $var_dir/data cache_dir: $var_dir/cache ext_dir: $var_dir/ext messages_dir: $var_dir/messages archive_dir: $var_dir/archives template_dir: $var_dir/templates root@mail:/var/log/mailman3#
Bingo! That may be the relict of a previous installation (at former times, without venv).
Shall I simply change
var_dir: /var/lib/mailman3
to
var_dir: /opt/mailman/web/logs
? Is a restart required?
oops.
And I have
# Directory where log files go. log_dir: /var/log/mailman3
Should be pointing to /opt/mailman/web/log , shouldn't it?
Where should the var_dir point to when using /opt/mailman/venv ?
Is that value correct:
# This is the root of the directory structure that Mailman will use to store # its run-time data. var_dir: /var/lib/mailman3
Please close as → solved.
The main reason was the old entry in the config file, which I apparently forgot to change.
Wikinaut writes:
For some unknown reason, an empty file /var/og/mailman/mailman.log was apparently owned by list:list. I deleted that file and mailman3 core could now be started. The start problem i solved.
I'm guessing you have a Debian or Ubuntu system, and there's some remnant of a Mailman installation (can't guess if it's 2 or 3). When you upgrade the package configuration script did it.
participants (3)
-
Odhiambo Washington -
Stephen J. Turnbull -
Wikinaut