[Mailman-Users] Uhhuh, my GID blues goes on... :(

Mark Sapiro msapiro at value.net
Thu Nov 24 20:09:17 CET 2005

Carl Zwanzig wrote:

>In a flurry of recycled electrons, Niemi Hannu wrote:
>> I have two sets of the lists:
>> 1) Lists that operate all right, when /etc/mailman/mailman.mail-gid is
>> 65533(nobody> ("vintage lists")
>> 2) Lists that operate all right, when /etc/mailman/mailman.mail-gid is 
>> 67 (mailman) (newly created lists)
>> The functionality is 100% repeatable all the lists in 1) function all
>> right eith 65533 and fail with 67 and all the lists in 2) function all
>> right with gid 67 and fail with 65533 with (now infamous error message):
>> <Hn11240914-l at listserv.kuntaliitto.fi>: Command died with status 2:
>>     "/usr/lib/mailman/mail/mailman post hn11240914-l". Command output:
>>     Failure to exec script. WANTED gid 65533, GOT gid 67.
>The wrapper program was compiled with gid 65535 (nobody). You need to 
>recompile it with gid 67 (mailman).
>> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
>Search for 'group mismatch', read 1.4 & 6.15 (and maybe 3.14)
>In short- set the group on -everything- in the mailman tree to mailman.
> Compile 'wrapper' to use gid mailman.
> Rerun check_perms again.

It is more complicated than that because some lists work and some don't.

Here's my take on it. I don't know the SuSE specific stuff, so I may be
off a bit, but I think I have it. I think the basic problem is there
are two different mail wrappers in different directories, one of which
expects to be invoked as group 65533 and is invoked by the "vintage
list" aliases and the other of which expects to be invoked as group 67
and is invoked by the "new list" aliases.

The new list aliases point to the wrapper in the directory set by
WRAPPER_DIR in Defaults.py/mm_cfg.py, and I suggest you keep that one
and delete the other wrapper and edit data/aliases to change all the
"vintage" wrapper paths to the "new" wrapper and run 'postalias' to
update the aliases.db. Then I think everything should work with 67 in

Presumably this situation came about because of changing the locations
of things during an upgrade of some sort. You might want to check to
see if there are other residual 'old' directories lying around and
delete them.

>>Is there some other list-specific files somewhere else in the file system?
>>If the group information for any other list-specific file is wrong, this
>>would make sense, but as now, I don't understand what CAN make the
>>difference between lists in those two hostile groups that just won't
>>play together ;)

As I indicate above, this group checking is done in the wrapper which
is not per se list specific. The list specific part is the aliases
that invoke the wrapper. Thus, I think it is the aliases that must be
different, and since the expected group is built into the wrapper, I
think there must be two wrappers.

Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

More information about the Mailman-Users mailing list