[Philip Hazel]
> It would be very easy to add two new options to Exim as follows:
>
> syslog_only write logging lines to syslog only
> syslog_also write logging lines to syslog and normal log files
Wouldn't a single configuration string list be better? I.e.,
Option: log_destination
Type: string-list
Default: "file"
This option specifies how Exim should do it's logging. The item
"file" specifies logging local files (see the `log_file_path'
option), while the item "syslog" specifies syslog()-style logging
(to syslog facility LOG_MAIL).
Or, maybe even allowing this (new) option to take over the
functionality of log_file_path if at all set:
Default: unset
This option specifies where Exim should put it's logs. The value is
a colon-separated list of items; each item specifies a separate log
destination. The special item "syslog" means that syslog()-type
logging should be done. All other items must start with "/", and
gives an absolute path to a directory in which Exim will write it's
log files.
If this option is not set, for backward compatibility
`log_file_path' will specify the log file directory.
... but that's maybe going too far -- I can't off the top of my head
think of any reason for wanting to log to more than one directory :)
> but there are some choices to be made. I think using the facility
> LOG_MAIL is clearly the right thing, but:
>
> (1) I agree with choice of LOG_INFO and LOG_ALERT suggested above, but
> not with LOG_DEBUG, because that is described as "Messages that contain
> information normally of use only when debugging a program". The only one
> that seems reasonble for rejectlog is LOG_NOTICE - "Conditions that are
> not error conditions, but that may require special handling".
I agree -- I guess the reason for me suggesting LOG_DEBUG was pure
lack of experience as to what actually goes into the reject log.
> The rejectlog, however contains copies of message headers. Writing
> these as separate lines could cause them to get interleaved in
> syslog, possibly causing confusion.
Indeed -- syslog will, when given a string containing newlines, prefix
only the first line with it's timestamp etc.
> (2) What to do about lines longer than 1024 characters. They could
> just be chopped, or written as multiple lines, with the
> continuations starting with some identifying string such as "...".
I like Peter Radcliffe's suggestion of continuation numbers.
One of the things I'm hoping is a goal when you're implementing syslog
support, is doing things in such a way that it will be feasible to run
(updated versions of) exigrep, eximstats etc. directly on the syslog
files. Piecing long log lines together will surely be easier if there
are continuation numbers included in the continuation prefix.
Besides, as most syslog implementations are UDP based, you could lose
some packets (and thus log lines) before they reach your log host. It
would certainly be a win (e.g. for exigrep) if such loss could easily
be detected by the lack of some continuation lines.
> (3) Should the pid be included in every logged line?
You're talking about calling openlog() with LOG_PID now, right? 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).
If you're talking about changing the format of the actual Exim log
text, I don't think that's needed (but I could be wrong).
> Judging by the syslog entries I've looked at, this will mess up the
> alignment at the start, but may be necessary to disentangle
> multi-line log entries.
Well, as the originating host name is part of the syslog prefix
anyway, the syslog line prefix will when you're logging to a central
log host -- which I suppose is the reason for wanting to use syslog
instead of local file logs. And, the "messed up factor" isn't worse
than m/(\[\d+\])?/, is it?
> (4) Presumably Exim's date/time should be chopped off.
If this would make it harder for exigrep etc. to deal with syslog
files, I'd rather not chop this info off. However, other people might
be more concerned with keeping the size of syslog files small, so this
might be nice to have as an option.
If Marc Haber's suggestion of making the log line format configurable
is feasible, at least the default format should be the one that
exigrep etc. will be able to parse.
--
Harald
