You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current behavior of logrotate halts the rotation process for all files when it encounters a file with an unexpected ownership, potentially leading to undetected disk space issues due to unrotated logs.
Expected Behavior:
Ideally, logrotate should continue to rotate those logs that do not present any ownership conflicts. This would ensure that manageable logs are properly rotated, preventing them from consuming excessive disk space.
Suggested Feature:
Introduce an option such as all-or-nothing which when set, logrotate will only proceed with rotation if all logs in a section can be rotated. Otherwise, it will skip the entire section. Or an option like rotate-when-possible could instruct logrotate to continue rotating files that do not have ownership or another issues, while only skipping the problematic files.
Benefits:
Prevents potential disk space issues by ensuring that at least some logs are rotated regularly.
Provides more granular control to system administrators over the log rotation process.
Allows for better handling of unexpected file ownership without halting the entire rotation process.
Additional Context:
This issue can lead to significant disk space consumption when logrotate encounters a file with incorrect ownership, causing it to stop rotating other files that are otherwise ready for rotation. By implementing a solution that allows for selective rotation, we can mitigate the risk of logs filling up disk space unnecessarily.
We have quite big list of logs gatering from remote hosts. Someone temporary created another logfile with "wrong" ownership. After few days logrotate complained not only about wrong ownership but also about all files that can't compress because due few days logs wasn't rotate and gzip had nothing to compress acording to configuration. Finding problematic folder wasn't so obvious while free disk space running away.
The text was updated successfully, but these errors were encountered:
Issue Summary:
The current behavior of logrotate halts the rotation process for all files when it encounters a file with an unexpected ownership, potentially leading to undetected disk space issues due to unrotated logs.
Expected Behavior:
Ideally, logrotate should continue to rotate those logs that do not present any ownership conflicts. This would ensure that manageable logs are properly rotated, preventing them from consuming excessive disk space.
Suggested Feature:
Introduce an option such as all-or-nothing which when set, logrotate will only proceed with rotation if all logs in a section can be rotated. Otherwise, it will skip the entire section. Or an option like rotate-when-possible could instruct logrotate to continue rotating files that do not have ownership or another issues, while only skipping the problematic files.
Benefits:
Prevents potential disk space issues by ensuring that at least some logs are rotated regularly.
Provides more granular control to system administrators over the log rotation process.
Allows for better handling of unexpected file ownership without halting the entire rotation process.
Additional Context:
This issue can lead to significant disk space consumption when logrotate encounters a file with incorrect ownership, causing it to stop rotating other files that are otherwise ready for rotation. By implementing a solution that allows for selective rotation, we can mitigate the risk of logs filling up disk space unnecessarily.
We have quite big list of logs gatering from remote hosts. Someone temporary created another logfile with "wrong" ownership. After few days logrotate complained not only about wrong ownership but also about all files that can't compress because due few days logs wasn't rotate and gzip had nothing to compress acording to configuration. Finding problematic folder wasn't so obvious while free disk space running away.
The text was updated successfully, but these errors were encountered: