atop (2.4.0-2) experimental; urgency=medium atop sometimes changes the format of the raw log files. In that case, atop -r will not be able to read the files written by previous version. The atopconvert(1) tool can be locally used to convert the old log files. In postinst, the package checks whether the new atop binary will read the latest raw file and try to convert the file. All other files in /var/log/atop are left unchanged. -- Marc Haber Tue, 22 Jan 2019 09:12:57 +0100 atop (2.4.0-1) unstable; urgency=medium atop 2.4 contains methods to collect data from nVidia GPUs. That feature is written in python and needs a python module that in turn needs the proprietary nVidia GPU driver. The module is not packaged in Debian at this time, and it would not be a good idea to depend on the proprietary nVidia stuff. Therefore, atopgpud has been removed in the Debian package. If you want to help with atopgpud being packaged, please file bug reports and patches. -- Marc Haber Fri, 18 Jan 2019 18:50:06 +0100 atop (2.2.6-3) unstable; urgency=medium atop does some really weird things with logrotate, which cause undocumented behavior in logrotate versions < 3.11. As Debian stretch has 3.11, this should not be an issue when updating between stable versions. If you have been using unstable or testing, and you get weird messages from logrotate, it might be worth looking in /var/log/atop for weird log files, and removing all dummy_* files other than dummy_after and dummy_before. -- Marc Haber Wed, 18 Jan 2017 19:39:45 +0100 atop (2.2.6-2) unstable; urgency=medium PID file /run/atopacctd.pid not readable (yet?) after start This is an issue when upgrading from one of the experimental atop versions that have never been in Debian unstable. I therefore don't consider it a bug. The issue is already reported (#842136, #849138). Please don't file additional bug reports for this issue. Here is an explanation from upstream (quoting Gerlof with his kind permission): |(…), I think that this caused by the fact that the previous run of |atopacctd did not terminate properly. That causes the fact that |files and directories are not removed by atopacctd, giving problems |with the next activation. |Obviously, it is possble to remove these files and directories |*during* the next activation (instead of terminating with an error |message). However, I don't want to do that since the existence of |the /run/pacct_shadow.d directory might also indicate that the |atopacctd daemon is already running (then a second incarnation |should refuse to start). |So when the issue is solved that atopacctd refuses to terminate (…), |the issue of the existing /run/pacct_shadow.d directory should also |be irrelevant IMHO. When atopacctd receives signal 2, 3 or 15, it finishes and destroys the files/directories it has created. If you encounter the situation that atopacctd does not start because it complains about pidfile and/or /run/pacct_* directories/files, please send SIGTERM to any atopacctd process that may still hang around, and if the files/directories are still there without the corresponding atopacctd process, please remove them manually and then try starting atopacctd again. -- Marc Haber Tue, 27 Dec 2016 12:00:00 +0100 atop (2.2.6-2) unstable; urgency=medium KERNEL ISSUES WITH PROCESS ACCOUNTING Newer upstream kernels have two issues with process accounting. These were isolated and debugged in #833997 1) Sometimes process accounting does not work at all¹. Atopacctd tries to work around this issue, by retrying to initialize process accounting several times. 2) When using the NETLINK interface, the command TASKSTATS_CMD_GET consequently returns -EINVAL². Atopacctd needs NETLINK to be able to be triggered that some process in the system has finished. In this way atopacctd can be in a blocking state as long as no processes terminate. When atopacctd detects this condition it thus switches into a polling state to periodically try if it can read process accounting records as a workaround. This issue has to do with cpumask and you can work-around it by building a kernel that has CONFIG_NR_CPUS configured to exactly the amount of CPUs (logical CPUs) in the system the kernel runs on. You can find this kernel option under "Processor type and features" --> "Maximum number of CPUs". [1] Bug 190271 - process accounting sometimes does not work https://bugzilla.kernel.org/show_bug.cgi?id=190271 [2] Bug 190711 - Process accounting: Using the NETLINK interface, the command TASKSTATS_CMD_GET returns -EINVAL https://bugzilla.kernel.org/show_bug.cgi?id=190711 Linux kernel mailing list thread: [REGRESSION] Two issues that prevent process accounting (taskstats) from working correctly https://lkml.org/lkml/2016/12/19/182 There are also Debian bug reports for those two issues, #848682 and #848683 -- Marc Haber Tue, 27 Dec 2016 12:00:00 +0100 atop (2.2.3-1~exp1) experimental; urgency=low * atop's log file format in /var/log has changed. Old log files will be moved away on upgrade so that the new atop will actually start. * currently the restart of atop does not work because in some circumstances, atop won't read its own log file. Symptom is that atop doesn't run after restart and /var/log/atop/daily.log says incompatible log format. Upstream has been informed of that. I am uploading to experimental to get preliminary comments from users. -- Marc Haber Mon, 08 Aug 2016 10:58:40 +0200