
On Wed, 30 Jan 2019 at 02:21, Mark Sapiro <mark@msapiro.net> wrote:
On 1/29/19 3:34 AM, Odhiambo Washington wrote:
I got an error this morning about some strange permission while run the cron.
Cron <list@lists> [ -x /usr/local/mailman/cron/senddigests ] && /usr/local/mailman/cron/senddigests:
Traceback (most recent call last): File "/usr/local/mailman/cron/senddigests", line 120, in <module> main() File "/usr/local/mailman/cron/senddigests", line 98, in main mlist = MailList.MailList(listname, lock=0) File "/usr/local/mailman/Mailman/MailList.py", line 133, in __init__ self.Load() File "/usr/local/mailman/Mailman/MailList.py", line 693, in Load dict, e = self.__load(file) File "/usr/local/mailman/Mailman/MailList.py", line 656, in __load fp = open(dbfile) IOError: [Errno 13] Permission denied: '/usr/local/mailman/lists/skunkworks/config.pck'
So I fumbled around trying to figure it out without success! bin/check_perms -f did not help either.
Was this a new list or one that was present during a prior successful cron/senddigests run?
It's an existing list.
Could you access the list via the web UI?
After fixing the issues I had with dns.resolver, the list is alive and I can do everything via the web UI. However, the cron errors still persist.
What user runs the cron, i.e. the owner of the crontab or the listed user is a system crontab, and can that user access the config.pck file? Can that user successfully run cron/senddigests manually?
The contrab file is in /etc/cron.d/ and is owned by root:root like all the files I see in there.
If the above doesn't give clues, maybe apparmor is involved.
I need to figure out what apparmor is. Heading to Google :)
Maybe it was a transient glitch.
It is not, because this morning I have seen permission problems with other aspects of the cron.
In any case, I wouldn't expect re-installing Mailman to correct a permissions problem if check_perms didn't find anything.
That is the strange part - check_perms -f isn't fixing it.
root@lists:/etc/cron.d# /usr/local/mailman/bin/check_perms No problems found
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)