Paul and myself have been working on the logging of dbmail.
Selective Logging:
We have moved in favor of a selective logging level system that better
mirrors syslog.
Differences:
Old:
6 Levels 0-5, each level including
Syslog logging only logged to levels alert or notice depending on severity.
New:
8 Levels, each can be turned on or off for both the errorlog and syslog
Syslog logging now logs to the level of the trace message. Thus a debug
message is logged to mail.debug
TRACE_FATAL is now TRACE_EMERG, and TRACE_ERROR is now TRACE_ERR to
match syslog.
TRACE_LEVEL is now fully depreciated and ignored. A TRACE error will be
generated
TRACE_SYSLOG and TRACE_STDERR are now depreciated and will throw a warning.
They will continue to accept 0-5 and will still be inclusive of higher
level messages.
The excerpt for the sample config file now in trunk better explains the
2 new variables and values to be set.
#
# Logging via stderr/log file and syslog
#
# Logging is broken up into 8 logging levels and each level can be
indivually turned on or off.
# The Stderr/log file logs all entries to stderr or the log file.
# Syslog logging uses the facility mail and the logging level of the
event for logging.
# Syslog can then be configured to log data according to the levels.
#
# Set the log level to the sum of the values next to the levels you
want to record.
# 1 = Emergency
# 2 = Alert
# 4 = Critical
# 8 = Error
# 16 = Warning
# 32 = Notice
# 64 = Info
# 128 = Debug
#
# Examples: 0 = Nothing
# 31 = Emergency + Alert + Critical + Error + Warning
# 255 = Everything
#
FILE_LOGGING_LEVELS = 7
#
SYSLOG_LOGGING_LEVELS = 31
Tracking Sessions:
The next item that I am working on is better tracking of what client
session is being worked on. Please chime in with some ideas on what you
would like to see in the TRACE messages that will help you monitor and
debug your systems.
I, personally, am in favor of logging the [IP:port] at the beginning of
each line something like this:
Sep 30 23:17:33 hostname dbmail-imapd[28116]: [0x8107040][New
Connection] Debug:[server] server_sock_cb(+387): 4 2, 0x816b080
Sep 30 23:17:33 hostname dbmail-imapd[28116]: [0x8107040][New
Connection] Info:[server] server_sock_cb(+408): connection accepted
Sep 30 23:17:33 hostname dbmail-imapd[28116]: [0x8107040][New
Connection] Notice:[clientbase] client_init(+95): incoming connection
from [127.0.0.1:65126] by pid [28116]
Sep 30 23:17:33 hostname dbmail-imapd[28116]:
[0x8107040][127.0.0.1:65126] Debug:[imapsession]
dbmail_imap_session_set_state(+1577): [0x8134180] state [0]->[1]
Sep 30 23:17:33 hostname dbmail-imapd[28116]:
[0x8107040][127.0.0.1:65126] Debug:[imap]
dbmail_imap_session_set_callbacks(+324): session [0x8134180], cb_read
[0x804eaa0], cb_time [0x804e810], timeout [60]
Sep 30 23:17:33 hostname dbmail-imapd[28116]:
[0x8107040][127.0.0.1:65126] Info:[clientbase] ci_write(+147):
[0x8114000] S > [* OK imap 4r1 server (dbmail 0.9.9)]
Sep 30 23:17:33 hostname dbmail-imapd[28116]:
[0x8107040][127.0.0.1:65126] Debug:[imap] socket_write_cb(+94):
[0x8134180] state [1] command_state [0]
Please keep in mind that lines are logged before the user logs in, so
some data like username may not be useful until later in the session as
there will be no user at first.
Other things we could do easily:
1. memory address of each session, like that of the thread id.
2. An incrementing number
3. The socket fd #, but it may be reused later.
I'll also be taking a look at existing TRACE calls through out the code
to both improve the message, set a proper trace level to take advantage
of our new levels, and add/delete trace calls where needed/useless.
Thats all for now.
-Jon
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
