restarting amavis as Postfix SMTP proxy

[Mark Martinec]

Florian,

> > I run amavisd-new as Postfix SMTP proxy. When I update my SpamAssassin
> > setup with sa-update, I have to restart amavisd in order to have the
> > new rules in effect. This only seems to be possible by using the
> > restart or force-reload command. However, during a timeframe of about
> > 10 seconds or so, any incoming SMTP connection will trigger a Queue
> > file write error, since the proxy is not reachable.
> > 
> > Is there any smarter way to have the new rules loaded, or is it best
> > to first stop Postfix, restart amavis and then start Postfix again? Or
> > does it make sense to play with the timeout values instead?

Patrick Ben Koetter wrote:
> which version of amavis are you using? Current versions of amavis know a
> real "reload" command, that will keep up service without any
> interruptions.

Indeed, the:

  # amavisd reload

is available since version 2.7.0.
It is extensively documented in release notes,
search for a 'reload' (several of them).

In summary:
- a re-purposed command line option 'reload' now does a warm restart,
  keeping sockets available to an MTA client at all times, thus reducing
  a chance that an MTA would even notice a content filter's warm restart.

[...]
- a command line option 'reload' has been re-purposed to function as a
  warm restart: it now sends a HUP signal to a running daemon, then exits.
  A running daemon upon receiving a HUP signal will clone its sockets,
  clear their 'close-on-exec' flag, then restart itself through exec().
  A reborn daemon inherits open sockets, does a normal startup (loading
  perl modules and config files), then reassociates inherited sockets
  with configured inet and Unix socket names, which is why these must
  not be changed in a configuration file between reloads.

  Sockets remain open and available to clients during the whole warm-restart
  period, requests are queued by kernel (queue size is configurable through
  $listen_queue_size, defaulting to SOMAXCONN, or there may not be any
  queues at all when an IP stack is using SYN cookies), so apart from a
  delay in connection establishment, an MTA client will not notice a restart
  as long as the IP stack is willing to accept new sessions (as controlled
  by listen queue size or SYN cookies). This makes the reloading method
  particularly suitable for pre-queue filter setups.
[...]


Mark