On 3/15/23 23:31, Pierre Malard via Mailman-users wrote:
File "/usr/lib/python3/dist-packages/flufl/lock/_lockfile.py", line 502, in _read with open(self._lockfile) as fp: PermissionError: [Errno 13] Permission denied: '/var/lib/mailman3/locks/dbcreate.lck' ——————————————————————————————————————————————————
CRON content: —————————————————————————————————————————————————— ... # Every 15 minutes, gate messages from usenet to those lists which have the gateway configured */15 * * * * list if [ -x /usr/bin/mailman ]; then /usr/bin/mailman gatenews; fi
Do you have any list's for which Gateway to mail is set to yes or for which there is a Linked Newsgroup?. If not, running gatenews is superfluous.
I thought, given the last line, a problem of rights. It is not the case ! The directory and the files contained in /var/lib/mailman3/locks belong to the user "list". When I run "/usr/bin/mailman gatenews" by hand everything is correct.
Can you do sudo -u list cat /var/lib/mailman3/locks/dbcreate.lck
. If
that succeeds, this may be a SELinux or other security manager issue.
The questions I have are these: We have 8000 files "dbcreate.lck..." in the directory "/var/lib/mailman3/locks". What are they for? Can we delete them?
They are probably all orphaned lock files due the the gatenews failure. To be certain that none are current you could stop Mailman core. Then with Mailman core stopped, any files in /var/lib/mailman3/locks are orphaned and should be removed.
We have 2 files "master.lck..." dated from the day after tomorrow ! What is this date? Aren't these files the problem?
Those files are normal. They are the master lock that prevents Mailman core from being started when it's already running. The future date is the way flufl.lock handles lock lifetimes. Locks when set have a lifetime, after which they can be broken. This is implemented in flufl.lock by setting the file's date that far into the future.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan