Hello Ramon, or anyone else affected,

Accepted logrotate into xenial-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/logrotate/3.8.7-2ubuntu2.16.04.2 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-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. 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 Trusty)
       Status: In Progress => Fix Committed

** Tags added: verification-needed-trusty

-- 
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     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to