Open mreynolds389 opened 1 year ago
Seems a good idea, but I wonder if we should not rather have explicitly 3 values: "on", "off", and "default" "default" means that buffering is enabled if log level is not the default one
There is an IPA need for "audit" log buffering. I will be working on this...
Audit log buffering
f19b93e17..791018702 389-ds-base-3.0 -> 389-ds-base-3.0 6eb3c3b34..d37958b48 389-ds-base-2.5 -> 389-ds-base-2.5 3a6695238..a9814b9b4 389-ds-base-2.4 -> 389-ds-base-2.4 0226e8774..327bedac5 389-ds-base-2.3 -> 389-ds-base-2.3 900bad76c..9180f4aa8 389-ds-base-2.2 -> 389-ds-base-2.2 7d1bc439a..921467392 389-ds-base-1.4.3 -> 389-ds-base-1.4.3
Somehow related to https://github.com/389ds/389-ds-base/issues/2474 Interesting idea about the double buffer logging
Issue Description
Currently only the access and security logs offer log buffering. Log buffering is needed for active logs so the server is not doing non-stop disk IO and slowing the server down.
We used to have a script, which has not worked in years, ds-logpipe.py. This script was typically used when enabling verbose error log levels. Instead of fixing this script (even if it's fixed it will break healthcheck while it's in use), if we add log buffering as an option for the error log it should prevent this server performance impact. Same for audit logs.
This should be tested, and if it works well then we should add log buffering as an option for all the DS logs (keep it off by default though).