Hello Ramon, or anyone else affected, Accepted logrotate into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/logrotate/3.8.7-2ubuntu3.1 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: logrotate (Ubuntu Zesty) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-zesty ** Changed in: logrotate (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags added: verification-needed-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to logrotate in Ubuntu. https://bugs.launchpad.net/bugs/1709670 Title: logrotate never recovers if the statefile is corrupted Status in logrotate package in Ubuntu: Fix Released Status in logrotate source package in Trusty: Fix Committed Status in logrotate source package in Xenial: Fix Committed Status in logrotate source package in Zesty: Fix Committed Status in logrotate source package in Artful: Fix Released Status in logrotate package in Debian: Unknown Bug description: [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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1709670/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : firstname.lastname@example.org Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp