Re: switching from exim to postfix
On 30.04.2012 16:55, Adam Borowski wrote:
> On Mon, Apr 30, 2012 at 11:58:18AM +0200, Carsten Hey wrote:
>> * Russ Allbery [2012-04-29 17:32 -0700]:
>> If dma would be the default MTA, then it should IMHO be as reliable as
>> possible and even try to prevent user errors. If a user would
>> unintentionally enables deferred mode (which is useful if you are behind
>> a dial-up line) but would not set up dma -q to run periodically, then
>> the mails would not be delivered without such a default cronjob.
>> A comment that reminds users to adapt the cronjob if needed should be
>> added to the config file. If dma -q is run every 5 minutes be default
>> anyway, the option -bq does not make that much sense anymore; this can
>> possibly be solved by implementing different ways of processing queued
>> mails. All in all, enabling the cronjob by default, as it is already
>> done in Debian, seems to be sane.
> Not on a laptop or any machine that has to conserve power and avoid
> unnecessary wakeups / disk spin-ups.
> A cronjob every 5 minutes means you need to start up the process, which adds
> quite a bit of churn. Worse, it will spam the logs, and since at least
> auth.log is fsync()ed after every write, it needs to spin up the disk.
> That's too big a price for a MTA on a system that typically goes months or
> years without a single mail.
Hmm.. Now when you mentioned it...
On all our postfix servers (yes we use postfix), I mount a tmpfs over
/var/spool/postfix/run, create subdirs "pid", "private" and "public"
in there and change corresponding dirs in /var/spool/postfix/ into
symlinks to run/$subdir.
Exactly in order to avoid extra disk wakeups every so often, by default
every 5min -- when qmgr gets woken up to re-scan its queue. This is
done by master process according to master.cf, master writes a byte
into corresponding /var/spool/postfix/public/qmgr FIFO, which results
in mtime of that inode being updated every 5 minutes. Oh well.
(And when I create these symlinks, `postfix check' starts reporting
wrong permissions on /var/spool/postfix/p* - since they becomes
FWIW, but Postfix also has this issue, unless it is set up very
carefully and in a non-standard way :)
(This is something I use since about 2002)