On Sun, Sep 21, 2025 at 3:56 PM Philip Bondi <pjbondi@systemdatabase.com> wrote:
Hello to everyone:
You are all superheroes. Thank you for your coaching. I would like to share my experience with this post
https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
I still had issue #931 after suggested work-around, so I used the following:
/opt/mailman/venv_mm/var/logs/*.log { daily dateext rotate 90 maxage 90 missingok sharedscripts postrotate if [ -r /opt/mailman/venv_mm/var/master.pid ]; then #sudo -u mailman /opt/mailman/venv_mm/bin/mailman restart &>/dev/null || true systemctl restart mailmanweb mailman3 fi if [ -r /opt/mailman/venv_mm/var/gunicorn.pid ]; then PID=
cat /opt/mailman/venv_mm/var/gunicorn.pidkill -s USR1 $PID fi endscript }
[snip]
I think it's good practice to have the var directory outside the virtual environment (venv). So you'd end up with /opt/mailman/mm/var/{archives,templates,logs,etc}. The official MM3 documentation lists it as /opt/mailman/mm/var. There is a good reason for it. During a major Python upgrade in the OS, you maybe forced to recreate your virtual environment. It is easier to: cd /opt/mailman/ mv venv venv.old python3 -m venv venv # create a new virtual environment
You see, your var directory is not affected in the process?? However, with yours, having everything below the venv, you'll be forced to move them outside during such major upgrade.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]