Permissions error on all Mailman overnights
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'
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
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
The new system's permissions don't define the locks directory as temporary, 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. ???
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.
As always, thanks in advance for assistance.
On 08/08/2015 08:12 AM, Steve Matzura wrote:
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.
Yes.
This looks OK, but presumably is irrelevant as it's not the system with the issue, right?
This looks OK too.
The new system's permissions don't define the locks directory as temporary,
That shouldn't be necessary.
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.
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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 scenario.
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.
Larry
-----Original Message----- From: Mailman-Users [mailto:mailman-users-bounces+larry=acbradio.org@python.org] On Behalf Of Mark Sapiro Sent: Saturday, August 08, 2015 11:19 AM To: mailman-users@python.org Subject: Re: [Mailman-Users] Permissions error on all Mailman overnights
On 08/08/2015 08:12 AM, Steve Matzura wrote:
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.
Yes.
This looks OK, but presumably is irrelevant as it's not the system with the issue, right?
This looks OK too.
The new system's permissions don't define the locks directory as temporary,
That shouldn't be necessary.
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.
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@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/larry%40acbradio.org
On 08/08/2015 10:26 AM, Larry Turnbull wrote:
I just checked the system and I see /var/spool/crontab/mailman.
OK, this is the user crontab for the user 'mailman'.
/etc/cron.d/mailman does not exist so it is running under the first scenario.
Normally /etc/cron.d/mailman does not exist in a source install. Some packages, e.g. Debian/Ubuntu, install this, but a source install doesn't.
If I type crontab -u mailman -l I can see the list of mailman cron jobs that are scheduled to run.
And what that does is just list the contents of /etc/cron.d/mailman.
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.
crons in crontabs in files /var/spool/crontab/XXX are run as user XXX.
What does
groups mailman
report? It should be 'mailman : mailman'. If so, and the crons are getting permission problems, check if SELinux is enabled and if so, try disabling it.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 08/08/2015 06:22 PM, Steve Matzura wrote:
But it was "mailman : postfix". Larry Turnbull fixed it by adding the 'mailman' group.
He reported this to me in an off-list message which I deleted thinking it had gone to the list.
You should be OK now. If not, post tracebacks from runs that abort going forward.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sat, 08 Aug 2015 18:47:29 -0700, Mark Sapiro <mark@msapiro.net> wrote:
No errors on the overnights, Things appear to be working correctly. I'm trying to run the password reminder job now, /var/log/messages shows it started twenty-three minutes ago, I haven't received any mail messages for password reminders on any of the lists on this system, so for all I know it may still be running and I'll just have to wait. If and when it finishes, I'll report.
On 08/09/2015 08:25 AM, Steve Matzura wrote:
It shouldn't take that long. What is the exact command you issued (or did you run it by modifying Mailman's crontab)? What if anything does
ps -fwwC python | grep mailpasswds
report?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 08/08/2015 08:12 AM, Steve Matzura wrote:
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.
Yes.
This looks OK, but presumably is irrelevant as it's not the system with the issue, right?
This looks OK too.
The new system's permissions don't define the locks directory as temporary,
That shouldn't be necessary.
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.
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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 scenario.
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.
Larry
-----Original Message----- From: Mailman-Users [mailto:mailman-users-bounces+larry=acbradio.org@python.org] On Behalf Of Mark Sapiro Sent: Saturday, August 08, 2015 11:19 AM To: mailman-users@python.org Subject: Re: [Mailman-Users] Permissions error on all Mailman overnights
On 08/08/2015 08:12 AM, Steve Matzura wrote:
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.
Yes.
This looks OK, but presumably is irrelevant as it's not the system with the issue, right?
This looks OK too.
The new system's permissions don't define the locks directory as temporary,
That shouldn't be necessary.
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.
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@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/larry%40acbradio.org
On 08/08/2015 10:26 AM, Larry Turnbull wrote:
I just checked the system and I see /var/spool/crontab/mailman.
OK, this is the user crontab for the user 'mailman'.
/etc/cron.d/mailman does not exist so it is running under the first scenario.
Normally /etc/cron.d/mailman does not exist in a source install. Some packages, e.g. Debian/Ubuntu, install this, but a source install doesn't.
If I type crontab -u mailman -l I can see the list of mailman cron jobs that are scheduled to run.
And what that does is just list the contents of /etc/cron.d/mailman.
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.
crons in crontabs in files /var/spool/crontab/XXX are run as user XXX.
What does
groups mailman
report? It should be 'mailman : mailman'. If so, and the crons are getting permission problems, check if SELinux is enabled and if so, try disabling it.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 08/08/2015 06:22 PM, Steve Matzura wrote:
But it was "mailman : postfix". Larry Turnbull fixed it by adding the 'mailman' group.
He reported this to me in an off-list message which I deleted thinking it had gone to the list.
You should be OK now. If not, post tracebacks from runs that abort going forward.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sat, 08 Aug 2015 18:47:29 -0700, Mark Sapiro <mark@msapiro.net> wrote:
No errors on the overnights, Things appear to be working correctly. I'm trying to run the password reminder job now, /var/log/messages shows it started twenty-three minutes ago, I haven't received any mail messages for password reminders on any of the lists on this system, so for all I know it may still be running and I'll just have to wait. If and when it finishes, I'll report.
On 08/09/2015 08:25 AM, Steve Matzura wrote:
It shouldn't take that long. What is the exact command you issued (or did you run it by modifying Mailman's crontab)? What if anything does
ps -fwwC python | grep mailpasswds
report?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Larry Turnbull -
Mark Sapiro -
Steve Matzura