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.
Yes.
> 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 expires.
> 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 <m...@msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
