Whether the log-file should be written to the filesystem or to
shared memory must now be explicitly defined when calling
skygw_logmanager_init() (instead of passing that via the argc/argv
construct).
Also, the meaning of '-l' when invoking maxscale has been changed.
Earlier -l [file|shm] specified whether the trace and debug logs
should be written to shared memory (while the error and message
logs always were written to the filesystem) and the _default_
was to write them to shared memory.
Now, with only one file, '-l' has still the same meaning, but it
decides whether the one and only logfile should be written to shared
memory, or the filesystem and the _default_ is to write it to the
filesystem.
If the log manager has not been inited, then messages are written
to stdout. In practice this can happen if something is directly or
indirectly logged during the startup of maxscale, before
skygw_logmanager_init() has been called. Some refactoring is needed
to allow skygw_logmanager_init() to be called very early at program
startup.
The previous interface of skygw_logmanager_init was conceptually
broken. With -o you could specify that logging should be done to
stdout. However, even if you did that, the log manager still checked
that the logging directory could be accessed. Unless it had been
specified using -j <path> the default was /var/log/maxscale.
That is, unless the program calling skygw_logmanager_init was invoked
by a user that had write access to /var/log/maxscale, there would be
a complaint even if nothing was ever written to that directory.
In practice this meant that even if -o was used you had to provide
a -j with a path that surely is writeable (e.g. "/tmp").
This has now been changed so that you explicitly must provide the
log directory and the flags -j and -o are removed.
bool skygw_logmanager_init(const char* logdir, int argc, char* argv[]);
If /logdir/ is provided then logged messages are written to a log file
in that directory. If /logdir/ is NULL then messages are logged to stdout
and no checks for access to any directory is not made.
The log manager variables lm_enabled_log_files_bitmask, log_ses_count
and tls_log_info that earlier were declared separately in every
c-file are now declared in the log_manager.h header.
The log manager possibility for explicitly specifying the names
of the log files has never been used. In the name of simplicity
that functionality is removed.
Some log manager refactoring to make it easier to later remove
all files but the error log.
Basically all that was done was to move everything inside the
for-loop of thr_filewriter_fun into a separate function called
thr_flush_file. Otherwise no changes in functionality was made.
logmanager_write_log did three different things - logged a message,
flushed a file and rotated a file - none of which were performed
in one go. Hence there's no reason to do all those things in that
function.
Another step on the road of log manager modifications.
- All messages are now logged to error.log. The other files are
still created but not used anymore.
- A severity prefix is added, to distinguish between messages logged
to "different" files:
LOGFILE_ERROR => "[Error]: "
LOGFILE_MESSAGE => "[Notice]: "
LOGFILE_TRACE => "[Info]: "
LOGFILE_DEBUG => "[Debug] "
That prefix is not written to syslog.
- When maxscale is built in debug mode, trace and debug messages
are no longer enabled by default.
Next step is to remove the other files entirelly.
Valist is handled before logmanager_write_log is called. So it
is quite unnecessary to always having to pass a valist whether
it is used or not (and not it is never used).
Augmentation moved to skygw_log_write_context. The severity prefix
will be added there as well. If all is done on that level, the
amount of memory needed can be figured out in one go. No need to
allocate and copy the message several times.
This commit is only to introduce new logging macros.
The current implementation is such that a statement like:
MAXSCALE_NOTICE("Refreshing configuration following SIGHUP\n");
is equivalent with
LOGIF(LM, (skygw_log_write(
LOGFILE_MESSAGE,
"Refreshing configuration following SIGHUP\n")));
The actual implementation will later be changed as the logging
mechanism itself is changed.
The names of the macros are now according to the levels of syslog
and currently the mapping is like:
MAXSCALE_ERROR (Syslog LOG_ERR) -> LOGFILE_ERROR
MAXSCALE_WARNING (Syslog LOG_WARNING) -> LOGFILE_ERROR
MAXSCALE_NOTICE (Syslof LOG_NOTICE) -> LOGFILE_MESSAGE
MAXSCALE_INFO (Syslog LOG_INFO) -> LOGFILE_TRACE
MAXSCALE_DEBUG (Syslog LOG_DEBUG) -> LOGFILE_DEBUG
When log manager is changed to deal "natively" with syslog levels
this mapping will disappear of course.
Straightforward indentation and whitespace modifications.
This is the first one in a series of commits that will bring
log manager in line with the coding style.
The log manager is initialized only once and skygw_log_sync_all now checks if the log manager has been successfully started before interacting with the log manager
Log message augmentation (appending of function name) can now
be enabled or disabled via the configuration file and command
line.
By default, the augmentation is disabled.
This change does not log the file name and line numbers,
but the function name. Together with the commit information
that is logged in conjunction with a crash and that MaxScale
can tell, when invoked, that is enough to be able to pinpoint
the location where a logging was made. Furthermore, that is
a lot less intrusive and less confusing for an
end-user than filename + line.
This is just a temporary workaround; the logging mechanism
needs to get an overhaul:
- Separate severity and logging target.
- Take syslog severities into use.
- Simplify what needs to be done by developer.
- etc.
