genaliases on Postfix is inefficient and can cause bounces

[Cedders-users]

We're running Mailman 2.1.5-8sarge5 and Postfix 2.1.5-9 on a mail server
with a few hundred lists. For reasons described on Bug [ 1809697 ], we run
genaliases as a cron job.

While genaliases is running, incoming posts and admin mail to some lists
can bounce, with "550 User unknown in virtual alias table". It appears
that genaliases loops over all lists and calls
MTA.create(mlist, nolock=True, quiet=quiet)
for each list, which in turn calls _update_maps() which runs Postfix's
postmap and postalias commands. Hence for a time while running genaliases
the list of mappings loaded into Postfix is incomplete. The process can
also take over a minute because of this repeated hashing.

Suggested fix (would patch on Bazaar but repository is empty :) -
add "if not nolock:" before
    _update_maps()
in Mailman/MTA/Postfix.py

and call "MTA.create(None, quiet=quiet)" once more before
    os.umask(omask)
in bin/genaliases

[http://sourceforge.net/tracker/index.php?func=detail&aid=1809706&group_id=103&atid=100103]

[Cedders-users (cedders-users)]

Originator: YES

The issue also appears to be present in 2.1.9.

[Mark Sapiro (msapiro)]

> and call "MTA.create(None, quiet=quiet)" once more before
> os.umask(omask)
> in bin/genaliases

Has this been tested? It looks like this will be a deadlock because genaliases has the lock at this point and MTA,create tries to obtain it. It seems that things need to be rearranged to

    finally:
        lock.unlock(unconditionally=True)
        MTA.create(None, quiet=quiet)
        os.umask(omask)

[Cedders (cedric-gn)]

Very good. I don't recall testing it, and wonder if it needs further testing with MTAs other than Postfix.

BTW the reference to Bug [ 1809697 ] is now launchpad bug 266407.

[Mark Sapiro (msapiro)]

It was tested with MTA = 'Manual' and MTA = 'Postfix' (the only supplied MTA modules) before being committed.