Am Freitag, 23. Dezember 2016, 20:10:23 CET schrieb Martin Steigerwald: > Am Freitag, 23. Dezember 2016, 19:37:33 CET schrieb Vincent Lefevre: > > On 2016-12-23 12:10:09 +0100, Marc Haber wrote: […] > > > I would appreciate if you could test that, by installing the version > > > from unstable and the upgrading to the current version in > > > experimental. That would _really_ help. > > > > It still fails: > > > > Preparing to unpack .../atop_2.2.6-1~exp1_amd64.deb ... > > Unpacking atop (2.2.6-1~exp1) over (1.26-2+b1) ... > > […] > > > but it doesn't fail on a different machine. I suppose that the problem > > comes from the fact that there hasn't been any clean-up after purging > > the buggy atop version: I still have the /run/pacct_shadow.d directory > > with old files: > > > > -rw-r--r-- 1 root root 0 2016-12-20 17:19:43 0000000000.paf > > -rw-r--r-- 1 root root 7 2016-12-20 17:19:43 current > > Yes. So to really test this: > > - Downgrade to atop 1.26 > - Reboot, or make sure atopacctd is stopped and remove /run/pacct_shadow.d > directory. > - Upgrade to 2.26. > > This should work okay every single time. Unless it doesn´t there is no > release critical bug.
I just downgraded to atop 1.26 and then upgraded to atop 2.26 twice. It just worked. Anytime I downgraded to atop 1.26 there was no /run/pacct_shadow.d present anymore. So it seems that on downgrading from from atop 2.26 to 1.26 atopacctd was properly stopped as it then removes its files and directories. (I didn´t check for the presence of atopacctd process.) > > But I wonder whether this may still be a problem. I mean that if > > atopacctd complains that some file exists, isn't this because it wants > > to recreate such a file, in which case the problem could occur again? > > I think there is. The one I already reported in bug #842136. > > But it is not release-critical. > > If you want to add some additional testing, you can try a reinstall of atop > 2.26 oder 2.26. If that doesn´t work, there is still an issue with atopacctd > not being able to be stopped gracefully. But I do think this is fixed. I also did this, but this fails due to a different issue: merkaba:~> LANG=C aptitude reinstall atop The following packages will be REINSTALLED: atop 0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not upgraded. Need to get 0 B/142 kB of archives. After unpacking 0 B will be used. (Reading database ... 581734 files and directories currently installed.) Preparing to unpack .../atop_2.2.6-1~exp1_amd64.deb ... Unpacking atop (2.2.6-1~exp1) over (2.2.6-1~exp1) ... Setting up atop (2.2.6-1~exp1) ... Failed to preset unit: File /etc/systemd/system/multi-user.target.wants/ atop.service already exists. /usr/bin/deb-systemd-helper: error: systemctl preset failed on atop.service: No such file or directory Processing triggers for systemd (232-8) ... Processing triggers for man-db (2.7.6.1-2) ... […] I will report this separately. And it isn´t an RC bug either. Thanks, -- Martin
