
Dear All,
I'm new to this list, but I've been using mailman for many years.
For a new project, I created seven identical lists (identical configuration) in seven different languages, all running on Mailman 2.1.15. This works fine for 6 lists.
The Japanese list however is behaving extremely strange. I'm not sure whether this is a bug or misconfiguration on my side.
The digest being sent out is the same one every day, and the new posts are just appended to it. So the daily digest is growing and growing and growing. (Just to clarify: I have not subscribed the mailing list address itself to the list! :)
I'm on shared hosting, so I haven't got full access to all files. But maybe someone here knows how to get it right. If it helps, my lists are accessible here: http://heidoc.net/mailman/listinfo
Thanks and best wishes,
Jan

Jan Krohn writes:
The Japanese list however is behaving extremely strange. I'm not sure whether this is a bug or misconfiguration on my side.
It's not due to it being Japanese. I've run Japanese lists for years with no such effect.
The digest being sent out is the same one every day, and the new posts are just appended to it.
That's incorrect, and it sounds like the digest file is not being deleted properly. Deleting a file requires write access to the containing directory, not to the file, so it's possible for the file to be appendable but not deletable.
Ask the host to run Mailman's check_perms script.

Stephen J. Turnbull wrote:
It certainly seems that Mailman's cron/senddigests is not removing the lists/LISTNAME/digest.mbox file after creating the digest. I doubt however that check_perms will find a problem. The lists/LISTNAME/ directory must be writable by Mailman as it also contains the list configuration files and every time the list is updated for a post or anything else, a new temporary config file is created and then the existing files all have their names changed so that the config becomes the backup and the new temporary file becomes the config, all of which requires write access to the directory.
My first thought is that cron/senddigests is not being run as the Mailman user, but that seems unlikely as other lists work.
The host also needs to check Mailman's error log which should contain clues.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Thanks for the replies so far. The host has reset the permissions. No digest was sent out today, which is a bit strange. The next run will show if everything's fine now...
Jan
-----Ursprüngliche Nachricht----- Von: Mark Sapiro [mailto:mark@msapiro.net] Gesendet: Dienstag, 11. Dezember 2012 12:34 An: Stephen J. Turnbull; Jan Krohn Cc: Mailman-Users@python.org Betreff: Re: [Mailman-Users] Digest growing to infinity
It certainly seems that Mailman's cron/senddigests is not removing the lists/LISTNAME/digest.mbox file after creating the digest. I doubt however that check_perms will find a problem. The lists/LISTNAME/ directory must be writable by Mailman as it also contains the list configuration files and every time the list is updated for a post or anything else, a new temporary config file is created and then the existing files all have their names changed so that the config becomes the backup and the new temporary file becomes the config, all of which requires write access to the directory.
My first thought is that cron/senddigests is not being run as the Mailman user, but that seems unlikely as other lists work.
The host also needs to check Mailman's error log which should contain clues.

Jan Krohn writes:
The Japanese list however is behaving extremely strange. I'm not sure whether this is a bug or misconfiguration on my side.
It's not due to it being Japanese. I've run Japanese lists for years with no such effect.
The digest being sent out is the same one every day, and the new posts are just appended to it.
That's incorrect, and it sounds like the digest file is not being deleted properly. Deleting a file requires write access to the containing directory, not to the file, so it's possible for the file to be appendable but not deletable.
Ask the host to run Mailman's check_perms script.

Stephen J. Turnbull wrote:
It certainly seems that Mailman's cron/senddigests is not removing the lists/LISTNAME/digest.mbox file after creating the digest. I doubt however that check_perms will find a problem. The lists/LISTNAME/ directory must be writable by Mailman as it also contains the list configuration files and every time the list is updated for a post or anything else, a new temporary config file is created and then the existing files all have their names changed so that the config becomes the backup and the new temporary file becomes the config, all of which requires write access to the directory.
My first thought is that cron/senddigests is not being run as the Mailman user, but that seems unlikely as other lists work.
The host also needs to check Mailman's error log which should contain clues.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Thanks for the replies so far. The host has reset the permissions. No digest was sent out today, which is a bit strange. The next run will show if everything's fine now...
Jan
-----Ursprüngliche Nachricht----- Von: Mark Sapiro [mailto:mark@msapiro.net] Gesendet: Dienstag, 11. Dezember 2012 12:34 An: Stephen J. Turnbull; Jan Krohn Cc: Mailman-Users@python.org Betreff: Re: [Mailman-Users] Digest growing to infinity
It certainly seems that Mailman's cron/senddigests is not removing the lists/LISTNAME/digest.mbox file after creating the digest. I doubt however that check_perms will find a problem. The lists/LISTNAME/ directory must be writable by Mailman as it also contains the list configuration files and every time the list is updated for a post or anything else, a new temporary config file is created and then the existing files all have their names changed so that the config becomes the backup and the new temporary file becomes the config, all of which requires write access to the directory.
My first thought is that cron/senddigests is not being run as the Mailman user, but that seems unlikely as other lists work.
The host also needs to check Mailman's error log which should contain clues.
participants (3)
-
Jan Krohn
-
Mark Sapiro
-
Stephen J. Turnbull