On 12 Sep 1999, Harald Meland wrote:
Thanks for your comments (and thanks to others who posted too). I'll
think about them all.
> Wouldn't a single configuration string list be better?
Hmm. It might even be an idea to extend the meaning of log_file_path
rather than invent a new option. It could be restricted to at most two
components, e.g.
log_file_path = syslog : /var/log/exim/%slog
> I like Peter Radcliffe's suggestion of continuation numbers.
If I were to generate the pid myself rather than let syslog do it, text
such as [1234.1] could be used to indicate line 1 of a multi-line entry
from process 1234, etc. Does this sound sensible?
> It
> would certainly be a win (e.g. for exigrep) if such loss could easily
> be detected by the lack of some continuation lines.
You could only detect the loss of the last line if its existence is
mentioned previously, so you would need something like [1234.1/4]
meaning "line 1 of 4". This makes the lines longer, but it is only in
the rejectlog that these multiple lines occur (except for the occasional
very long mainlog line) so the extra space isn't a great issue, I feel.
> You're talking about calling openlog() with LOG_PID now, right?
I was, but Exim could easily generate it itself.
> If
> so, I think it should -- bearing in mind that this won't be possible
> on e.g. ULTRIX boxes (as ULTRIX openlog() have no such option).
As far as I know, ULTRIX is the only OS supported by Exim that has this
problem, and I don't think it is a major OS these days. However, by
generating the pid within Exim this problem goes away.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.