Systemd, Spamassassin, and the Missing Portreserve Package

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Thu Feb 5 22:53:22 UTC 2015


On Thu, Feb 05, 2015 at 03:44:29PM -0600, Chris Adams wrote:
> Once upon a time, Tomasz Torcz <tomek at pipebreaker.pl> said:
> >   Cleaner way would be to implement socket activation in spamd. I've
> > looked into doing this.  After looking into spamd I have no idea
> > how to implement sock-act cleanly.
> 
> SA is definitely (of course IMHO) one of the types of things that should
> not use socket activation.
This is a complete misunderstanding.

Socket activation does not determine when the process is started.
Depending on the configuration, it may be started during boot or
after first request.

Essentially, with the usual setup of having two units (e.g. spamd.socket and spamd.service),

1. add spamd.socket to sockets.target → the socket is started during boot
                                   and spamd.service will be started on first request
2. add spamd.service to multi-user.target → the service is started during boot

> It is high overhead to start up (takes a
> while to initialize), and things trying to use it that way could time
> out.
I doubt that... How low does it take to start? A second, two seconds?
Having a delay on every access to the service would of course be noticable,
but just on the first one — I don't think anyone would notice if one
mail takes 2s longer to arrive.

> The general expectation with SA is that if you want fast response,
> use you spamd (started up at boot).  If you don't care about the
> start-up time, you just use spamassassin directly.
> 
> Aside from that, I don't know if someone has set up socket activation
> for anything in perl.  I guess it is using file descriptor passing?  I
> haven't done that in perl before (although shouldn't be too hard).
I doesn't use "file descriptor passing", at least not in the sense of
attaching sockets to messages. The process is simply started with
an additional fd open: 0:stdin, 1:stdout, 2:stderr, 3:socket.

Zbyszek


More information about the devel mailing list