[Mailman-Users] Permissions error on all Mailman overnights

Larry Turnbull larry at acbradio.org
Sat Aug 8 19:26:30 CEST 2015

I am working with Steve on this one as well.

I just checked the system and I see /var/spool/crontab/mailman.

/etc/cron.d/mailman does not exist so it is running under the first

If I type crontab -u mailman -l I can see the list of mailman cron jobs that
are scheduled to run.

I am trying to figure out what user the cron system is trying to run the
mailman crons as as that is where I think the problem lies.

Running /usr/local/mailman/bin/check_perms reports no problems so I think we
are good on how permissions are set on the files and folders.

The lists themselves are working fine it is just the cron jobs where things
are a bit odd.


-----Original Message-----
From: Mailman-Users
[mailto:mailman-users-bounces+larry=acbradio.org at python.org] On Behalf Of
Mark Sapiro
Sent: Saturday, August 08, 2015 11:19 AM
To: mailman-users at python.org
Subject: Re: [Mailman-Users] Permissions error on all Mailman overnights

On 08/08/2015 08:12 AM, Steve Matzura wrote:
> Every night, I get the following error at the bottom of a mail message 
> to my mailman list telling me that checkdbs, digest and disabled
> failed:
> IOError: [Errno 13] Permission denied:
> '/usr/local/mailman/locks/mailman.lock.{my-FQDN}.{some-number}.0'

So cron/checkdbs cant create a lock.

How are these crons running? Are they run form a user crontab
(/var/spool/cron/mailman ?) or a system crontab (/etc/cron.d/mailman ?)?

If the latter, what's the user nsame in the crontab entries.

> This also happened on the one and only password reminder message that 
> went out over a week ago, which no one received.
> {some-number} is presumably the process ID of the job's process.


> Here are descriptions of the locks directory on the old and new 
> systems--i.e., the one that works, and the one with the job failures.
> The old system is Debian 4, from 2009, which has not received any 
> software upgrades since 2010. 'list' is the name of the Mailman user 
> and group. The locks directory, /var/lib/mailman/locks, is defined
> thus:
> lrwxrwxrwx 1 root root 18 2009-05-01 02:31 locks -> ../../lock/mailman 
> drwxrwxrwt 4 root root 4096 2015-08-08 02:56 lock drwxrwsr-x 2 root 
> list 4096 2015-08-08 12:00 mailman

This looks OK, but presumably is irrelevant as it's not the system with the
issue, right?

> On the new Fedora 20 system with hand-built Mailman up to date, 
> 'mailman' is its username and group, and the locks directory, 
> /usr/local/mailman/locks, is defined thus:
> drwxrwsr-x 2 root mailman 4096 Aug  8 14:37 locks

This looks OK too.

> The new system's permissions don't define the locks directory as 
> temporary,

That shouldn't be necessary.

> although at this very moment there are files in it--master-qrunner, 
> and master-qrunner.{my-FQDN}.{some-number}, both of which have 
> *tomorrow's* dates on them. ???

Those are the master qrunner locks and should be there if Mailman is
running, and the future date is normal. That's the time at which the lock

> I'm thinking the locks directory may be at fault here, and if it is, 
> what was done wrong when Mailman was built or configured? This is 
> important not just because the mail system is not running correctly at 
> this time, but because I will be installing a second instance of 
> Mailman to support a new domain I'll be hosting, so I'm thinking 
> whatever I did wrong the first time will happen again, unless I 
> prevent it.

Your locks directory is fine. The master qrunner can create its locks and
the running Mailman and presumably the web CGIs can lock and unlock lists
which is done repeatedly. Your only issue seems to be with crons.
This must be either an issue with the user:group running the crons or a
security policy (SELinux or ?) issue.

Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan
Mailman-Users mailing list Mailman-Users at python.org
Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy:
http://wiki.list.org/x/QIA9 Searchable Archives:

More information about the Mailman-Users mailing list