** Description changed: [Impact] - logrotate never recovers if the statefile is corrupted unless you remove it or fix the corruption by hand. - System will eventually run out of disk space on /var/log for instance. + logrotate never recovers if the statefile is corrupted unless you remove + it or fix the corruption by hand. + + Impact scenarios : + - System could eventually run out of disk space on a separate partition if mounted in "/var" or specifically "/var/log" or even worst if "/var/log" is on the same partition as "/" it could create even more damage if by any chance the partition is running out of free space. + + - System keep updating the same files over and over, creating large size logfiles. + - ... [Test Case] - Install logrotate - Run "/etc/cron.daily/logrotate" ## The first logrotate run will generate the statefile "var/lib/logrotate/status" - Modify "/var/lib/logrotate/status" by removing the first line in order to corrupt the file - Re-run "/etc/cron.daily/logrotate" and one will get the following error : "error: bad top line in state file /var/lib/logrotate/status" every time you run logrotate Unless you remove the statefile and start again or fix the corruption by hand. [Regression Potential] * Risk of potential regression is low, and IMHO couldn't be worst than the actual situation where logrotate simply doesn't recover from a corrupt statefile. * The current patch does recover (after verification) and has been through some upstream CI validation, community feedbacks, et al. * Additionally, I will run the /path_to_source/test/test script as a dogfooding that does ~72 tests. [Other Info] * Upstream commit: https://github.com/logrotate/logrotate/commit/b9d82003002c98370e4131a7e43c76afcd23306a * Upstream bug: https://github.com/logrotate/logrotate/issues/45 * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871592
** Description changed: [Impact] logrotate never recovers if the statefile is corrupted unless you remove it or fix the corruption by hand. Impact scenarios : - - System could eventually run out of disk space on a separate partition if mounted in "/var" or specifically "/var/log" or even worst if "/var/log" is on the same partition as "/" it could create even more damage if by any chance the partition is running out of free space. - - System keep updating the same files over and over, creating large size logfiles. + - System could eventually run out of disk space on a separate partition + if mounted in "/var" or specifically "/var/log" or even worst if + "/var/log" is on the same partition as "/" it could create even more + damage if by any chance the partition is running out of free space. + + - System keep updating the same files over and over, creating large size + logfiles. + - ... [Test Case] - Install logrotate - Run "/etc/cron.daily/logrotate" ## The first logrotate run will generate the statefile "var/lib/logrotate/status" - Modify "/var/lib/logrotate/status" by removing the first line in order to corrupt the file - Re-run "/etc/cron.daily/logrotate" and one will get the following error : "error: bad top line in state file /var/lib/logrotate/status" every time you run logrotate Unless you remove the statefile and start again or fix the corruption by hand. [Regression Potential] * Risk of potential regression is low, and IMHO couldn't be worst than the actual situation where logrotate simply doesn't recover from a corrupt statefile. * The current patch does recover (after verification) and has been through some upstream CI validation, community feedbacks, et al. * Additionally, I will run the /path_to_source/test/test script as a dogfooding that does ~72 tests. [Other Info] * Upstream commit: https://github.com/logrotate/logrotate/commit/b9d82003002c98370e4131a7e43c76afcd23306a * Upstream bug: https://github.com/logrotate/logrotate/issues/45 * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871592 ** Description changed: [Impact] logrotate never recovers if the statefile is corrupted unless you remove it or fix the corruption by hand. Impact scenarios : - System could eventually run out of disk space on a separate partition if mounted in "/var" or specifically "/var/log" or even worst if "/var/log" is on the same partition as "/" it could create even more damage if by any chance the partition is running out of free space. - System keep updating the same files over and over, creating large size logfiles. - ... [Test Case] - Install logrotate - Run "/etc/cron.daily/logrotate" ## The first logrotate run will generate the statefile "var/lib/logrotate/status" - Modify "/var/lib/logrotate/status" by removing the first line in order to corrupt the file - Re-run "/etc/cron.daily/logrotate" and one will get the following error : "error: bad top line in state file /var/lib/logrotate/status" every time you run logrotate Unless you remove the statefile and start again or fix the corruption by hand. + * Additionally, I will run the /path_to_source/test/test script as a + dogfooding that does ~72 tests. + [Regression Potential] * Risk of potential regression is low, and IMHO couldn't be worst than the actual situation where logrotate simply doesn't recover from a corrupt statefile. * The current patch does recover (after verification) and has been through some upstream CI validation, community feedbacks, et al. * Additionally, I will run the /path_to_source/test/test script as a dogfooding that does ~72 tests. [Other Info] * Upstream commit: https://github.com/logrotate/logrotate/commit/b9d82003002c98370e4131a7e43c76afcd23306a * Upstream bug: https://github.com/logrotate/logrotate/issues/45 * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871592 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1709670 Title: logrotate never recovers if the statefile is corrupted To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1709670/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
