Hi all
I've just been mulling something over (in my head, mainly) while looking
at processing statistics from one of the machines under my control.
It struck me that if Exim was able to log to a pipe - i.e. send the
output it normally puts in the various other logs out to a child process
via a pipe - that we'd greatly extend the functionality and availability
of real-time stats packages which can monitor Exim and spit out graphs,
reports, alerts and so on.
I've had a brief scan of Bugzilla and can't see this mentioned there,
nor could I find mention of it in the -dev archive (and only one request
in the -users archive) so chewed on it a bit more. And then it hit me:
The way Exim spins off and reaps child processes - for deliveries and so
on - means that they themselves write to the various logfiles. In order
to write to a pipe, all the child processes need to know where/what that
pipe is. In the case of, for example, a manually- fired queue run, that
information pretty much won't exist and the child would therefore need
to run up the pipe itself.
Very quickly, on a busy server, we're talking about a massive overhead
(especially where Perl or other interpreted languages are used) -
spinning up, piping to, and reaping a child process for every
sub-process Exim generates. This is clearly a non-trivial load.
Am I missing the point, or have I fundamentally understood an issue
which would make logging to a pipe all but impossible?
As an adjunct to this... if the main/panic/reject logs were made FIFOs
instead, would that gain us anything (and I suspect the answer is "only
if you can guarantee something is on the other side of them").
Graeme
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
I've just been mulling something over (in my head, mainly) while looking
at processing statistics from one of the machines under my control.
It struck me that if Exim was able to log to a pipe - i.e. send the
output it normally puts in the various other logs out to a child process
via a pipe - that we'd greatly extend the functionality and availability
of real-time stats packages which can monitor Exim and spit out graphs,
reports, alerts and so on.
I've had a brief scan of Bugzilla and can't see this mentioned there,
nor could I find mention of it in the -dev archive (and only one request
in the -users archive) so chewed on it a bit more. And then it hit me:
The way Exim spins off and reaps child processes - for deliveries and so
on - means that they themselves write to the various logfiles. In order
to write to a pipe, all the child processes need to know where/what that
pipe is. In the case of, for example, a manually- fired queue run, that
information pretty much won't exist and the child would therefore need
to run up the pipe itself.
Very quickly, on a busy server, we're talking about a massive overhead
(especially where Perl or other interpreted languages are used) -
spinning up, piping to, and reaping a child process for every
sub-process Exim generates. This is clearly a non-trivial load.
Am I missing the point, or have I fundamentally understood an issue
which would make logging to a pipe all but impossible?
As an adjunct to this... if the main/panic/reject logs were made FIFOs
instead, would that gain us anything (and I suspect the answer is "only
if you can guarantee something is on the other side of them").
Graeme
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
