Age | Commit message (Collapse) | Author |
|
* kpy3/fix-fd-leak-in-logger/OTP-15997:
Close log files in case of inode change properly
|
|
|
|
If the log file name was given as a relative path, logger_std_h
erroneously tried to create a new file in a new location if the
current working directory of the node was changed. This is now
corrected.
|
|
OTP-15663
This option indicates how often the handler shall check if the log
file still exists and if the inode is changed.
|
|
OTP-15479
OTP-15662
New configuration map for logger_std_h:
#{type => file,
file => file:filename(),
modes => [file:mode()],
max_no_bytes => pos_integer() | infinity,
max_no_files => non_neg_integer(),
compress_on_rotate => boolean()}
For backwards compatibility, the old variant for specifying the file
name via the 'type' parameter is still supported, i.e. {file,FileName}
and {file,FileName,Modes}, but it is no longer documented.
Rotation scheme:
The current log file always has the same name, and the archived files
get extensions ".0", ".1", ... The newest archive has extension ".0",
and the oldest archive has the highest number.
If 'compress_on_rotate' is set to true, the archived files are gzipped
and get the additional extension ".gz", e.g. error.log.0.gz.
Rotation is turned off by setting 'max_no_bytes' to infinity. Setting
'max_no_files' to 0 does not turn off rotation, but only specifies
that no archives are to be saved.
|
|
OTP-15602
It is allowed to set file modes for the handler to use when opening
its log file. The given modes were earlier accepted without any
checks, which could make the handler behave unexpectedly. This commit
makes sure that
* if none of write, append or exclusive is given, then append is added
* if raw is not given, it is added
* if delayed_write or {delayed_write,_,_} is not given, then
delayed_write is added
|
|
|
|
Earlier, if the log file had to be re-opened, e.g. due to it being
renamed or removed, it would always be opened with the default file
options, even if other options were set in the configuration.
Now, the configured options are used, except that 'append' is always
added and 'exclusive' is always removed.
|
|
If the inode changes, the file is now reopened. This may happen, for
instance, if the log file is opened and saved by an editor.
|
|
These are not documented, and only used in test. The test now uses
logger_olp directly instead.
|
|
The new file logger_olp.hrl is added.
|
|
This is an update to logger_std_h, which makes it play well with tools
like logrotate.
|
|
|
|
There was a lot of duplicated code in logger_std_h and
logger_disk_log_h. Most of this is now moved to logger_h_common, which
now also serves as the gen_server callback.
|
|
This function is called when a logger API function for fetching
handler configuration is called. The point is to allow the handler to
remove internal data fields that it might have stored in the
configuration database, before returning the handler configuration to
the caller.
An example of such internal data are the 'handler_pid' and 'mode_tab'
fields that logger_std_h and logger_disk_log_h store in their
configuration maps.
|
|
The new parameter to this function, SetOrUpdate, indicates how
unspecified configuration data fields shall be set. The rule is that
if SetOrUpdate equals set, then default values shall be used, and if
SetOrUpdate equals update, then existing configuration values shall be
used. Consequently, these examples now apply to logger_std_h and
logger_disk_log_h:
set_handler_config(default, config, #{sync_mode_qlen => 20}) sets the
value of sync_mode_qlen to 20, and resets all other (writable) fields
in the config map to their default values.
update_handler_config(default, config, #{sync_mode_qlen => 20}) sets
the value of sync_mode_qlen to 20, and leaves all other fields in the
config map unchanged.
|
|
When a handler process is terminated due to overload, it reads its
configuration from the configuration database, so it can be restarted
with the same configuration after a small delay. This was earlier done
in a different process, which was spawned off from the terminate
function. This caused a race condition, where in some cases, the
configuration was already removed before it could be read.
The reason for spawning off a process, is to avoid a deadlock due to
the call to logger:remove_handler/1.
This commit moves the call to logger:get_handler_config/1 back to the
handler process - to ensure that the data is still there, but keeps
the call to logger:remove_handler/1 in the spawned off process - to
avoid deadlock.
|
|
|
|
|
|
|
|
|
|
* siri/logger-fix:
[logger] Update documentation
[logger] Adjust priority settings in test
[logger] Unregister handler names before terminating
[logger] Stress overload_kill tests in disk_log handler
|
|
|
|
|
|
Conflicts:
lib/kernel/src/logger_disk_log_h.erl
|
|
|
|
|
|
|
|
Conflicts:
lib/kernel/src/logger_disk_log_h.erl
lib/kernel/src/logger_std_h.erl
|
|
And add field 'module' in handler config.
|
|
|
|
logger_std_h:filesync/1 -----> logger_std_h:sync/1
logger_disk_log_h:disk_log_sync/1 -----> logger_disk_log_h:sync/1
|
|
|
|
|
|
* peppe/peppe/kernel/logger_handler_fixes:
Various logger handler improvements and updated test cases
Make it possible to disable sync and drop mode
Conflicts:
lib/kernel/test/logger_disk_log_h_SUITE.erl
lib/kernel/test/logger_std_h_SUITE.erl
|
|
|
|
|
|
|