1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
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 <mh+debian-packages@zugschlus.de> 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 <mh+debian-packages@zugschlus.de> 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 <mh+debian-packages@zugschlus.de> 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 <mh+debian-packages@zugschlus.de> 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 <mh+debian-packages@zugschlus.de> 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 <mh+debian-packages@zugschlus.de> Mon, 08 Aug 2016 10:58:40 +0200
|
