[Mailman-Users] Tricky admin_immed_notify problem

[Savoy, Jim]

>>Jim Savoy wrote:

>>  I am not all that familiar with cron. Is that "crontab -u mailman
>>crontab.in" something you need to run every time you reboot the
system?
>>Or does it add something to /etc/cron.d or /etc/cron.daily or
/etc/crontab?
>>(I don't see anything new in those).

>Mark Sapiro wrote:

>As you discovered it puts the commands from crontab.in into the mailman
>user's crontab which is likely /var/spool/cron/mailman. It stays there
>across boots.

>This is the correct place for the mailman crontab. The ones in cron.d
are a slightly different format.

Got it. And yes, there is an entry now in /var/spool/cron for mailman.

>But note, that almost all the jobs in crontab.in should be run. They
all have a function and the only one you can safely ignore is
gate_news if you aren't running any lists with a news->mail gateway.

I will run more of them eventually. Since we hadn't run any of these
in years (ever, in fact) I thought it might be a bad idea to "release
the
hounds" all at once. The madness that took place with the "-1 pending
requests"
confirmed that. By the way - thanks for your excellent script. Saved me
and
the owners the hassle of fixing the minus-one problem (243 lists were in
that
state and they are all fixed now!).

>For the others, you need to at least read the comments in crontab.in
and understand what the job does before deciding not to run it.

I will probably leave the gateway news stuff out forever. And also the
password
reminder thing, as we don't want to bombard our students with more info
(most
of our 900+ lists are NOT opt-in, and most are read-only, and we rotate
thousands
of different users through these lists each semester, without their
knowledge).
I probably won't run the "disabled users" reminder either, for the same
reason
as above.

So that just leaves two more things to run via cron: digests and archive
gzipping.
I will run the digests thing next and if that goes smoothly, unleash the
archive gzipping. 

>This issue only existed with lists that were migrated from pre 2.1.5 to
2.1.5 and only exists in 2.1.5.

Precisely our situation. Thanks.

 - jim -