Reorganizing log levels

[ikedas]

Currently, err and notice, or info and notice levels are sometimes confused. And, err level outputs traceback to syslog even when the error was caused by user.

So I wish to clarify the purpose of each log level.

See also issue #64.

Summary of proposal

• err level will be separated to crit, intern and user.

• user level will be used for information caused by users' action. crit, intern and notice levels will be used for the system.

• notice and info level will be used for successful result.

• debug* levels will be used for things not corresponding to any levels above.

• trace level will be deprecated.

Comparison

Logging levels are approximatily associated as the table below.

Syslog (*1)	Report (*2)	This proposal	comment
err	-	crit	When process died
err	intern	intern
err	auth	user	Authorization by scenario failed
err	user	user
notice	notice	notice
info	-	info
debug*	-	debug*
trace	-	-

(*1) Sympa::Log::syslog() and wwsympa's wwslog(). (*2) Sympa::Report::reject_report_web() and Sympa::Report::notice_report_web().

Detailed description

crit: Unrecoverable error: Program cannot continue processing.

In other words, Sympa has no choice but to die.

e.g.:

• Mandatory file or directory (such as spool) does not exist, cannot be open or not be writable.
• Unrecoverable errors in sympa.conf or robot.conf (such as malformed parameter value without default).
• Program died (including the case that die() was explicitly executed).
• and other failure to prevent running the program.

Side-effects:

• This level outputs traceback to log and STDERR.
• Sympa will die.

intern: Internal server error

Precisely, recoverable failures corresponding to foreign component (database, MTA, DNS, ...) and operating system (virtual memory, filesystem, network, ...).

e.g.:

• Cannot open existing and readable file, or cannot read from/write to the opened file.
• Storing a message into the spool failed.
• Submitting one or more messages to MTA failed.
• Logging failed.
• Database server was (temporarily or permanently) gone.
• Query was denied by SQL or LDAP server.
• DNS returned malformed response (DKIM etc.).
• CAS server unexpectedly denied ticket.
• Synchronization of list members unexpectedly failed.
• ... and other errors interacting with foreign components.

Side-effects:

• This level outputs traceback to log.
• This level sends notification to the listmaster.

user: Errors caused by incoming messages, users or clients

In other words, errors caused by inputs from outside of Sympa.

e.g.:

• Errors in list config file (list does not have owners etc.).
• Errors in configuration file except sympa.conf and robot.conf.
• Errors in TT2 template.
• Mail loop was detected.
• Cannot parse MIME.
• Cannot verify signature of message, or cannot decrypt message.
• Authentication failed.
• Entity (robot, list, family, user, ...) specified by user or client was not found.
• Incorrect mail command in the message.
• Mail command failed.
• Incorrect parameter(s) in request from user or client, or mandatory parameters did not be given.
• Authorization failed: Action by user was inhibited (e.g. by scenario).
• Message was ignored by other reason (e.g. No senders).
• ... and other errors caused by inputs from outside of Sympa.

Side-effects:

• This level DOES NOT output traceback nor send notification.

notice: Epochal events on the system

e.g.:

• Program starts, forks or expectedly terminates.
• Database structure was successfully updated.
• Temporary failure is solved (database connection restored etc.)
• List is created, instantiated, closed, restored or purged.
• ... and so on.

info: Other succseeful events

e.g.:

• New message was fetched from spool.
• A message was added into spool.
• A message was sent successfully.
• Authentication by user suceeded.
• List member(s) are added, deleted or successfully synchronized.
• Mail command succeeded.
• Action by user (partially or completely) succeeded.
• Statistical information.
• ... and other information not related to errors nor debugging.

Note on user, notice and info levels

The notice means what the administrators are interested in. Conversely, info and user levels mean what users are interested in: Facts like who mistyped password, who is added to which list, how a list distributes messages, ... and so on are relatively less important for administrators.

debug, debug2 or debug3: Debugging information

e.g.:

• Information for tracing or profiling.
• AND, everything not corresponding to other log levels.

---

EDIT

2021-10-09 For clarification, description about "operating system" on "intern" level was added. 2021-10-10 Added description of notification with intern level.