On 2013-08-08 at 15:26 +0200, Marcin Gryszkalis wrote:
> On 2013-08-08 09:53, Phil Pennock wrote:
> > records with A=<authenticator>:$authenticated_id which user
> > authenticated to try to send the email (thus the need to use
> > server_set_id) and early in the log-line you have a [pid] field in
> > square brackets.
>
> As I dislike the idea of parsing log files (takes too long etc.) - but
> another idea came to my mind after reading your advise - I can save
> pair(pid,autenticated_id) to database with pid as unique key (to solve
> pid reuse) and simple select+kill would do.
That only works if all processes reachable by the killer are receiver
processes. Otherwise, a process forked to be a transport for delivery,
for instance, becomes susceptible to killing.
So it's not even worth worrying about "unauthenticated inbound-to-MX"
connections or killing the daemon -- the DB you propose would be
incomplete.
If your C is decent, you might add support to Exim for evaluating a
string as a post-condition in the daemon after reaping a child process,
with the child process pid in an expansion variable, such that you could
say:
daemon_post_incoming = ${lookup sqlite {AUTHPIDSDBFILE \
DELETE FROM auth_pids WHERE pid='${quote_sqlite:$reaped_pid}'}}
This then only assumes that the daemon will be scheduled and run for
long enough to evaluate reaped child hooks, before the pid space is
cycled. Given that there will be a blocking zombie until you get the
pid reaped, that's a very small window which should be safe in all but
the most exotic of scheduling snafus.
-Phil
