Bug#999448: atop: Two fixes for debian/rules: activate atopacctd before activating atop, load atop.default into pkg
Fei Li
Version: 2.6.0-2
Severity: normal
Dear Maintainer,
Thanks for your supporting and maintaining debian atop package, we
have been running atop as a quite useful monitoring tool in bytedance
for years. But recenly, when trying to make a new package based on
2.6.0-2, we find two unexpected behaviors in debian/rules file
(although these two have been there for long times, we just notice
them recently :) ).
1st. Should activate atopacctd before activating the atop daemon.
* Backgournd
Reading from atop mannual, we know that there are four ways to get
access to the terminated process accounting records:
- environment variable ATOPACCT
- the atopacctd daemon (the preferred way)
- the separate psacct package
- using the file /var/cache/atop.d/atop.acct
* Problem
By reading the source code, to use the preferred way: atopacct daemon,
we should ensure that atopacctd starts before atop. But the current
mechanism is that atop starts earlier than atopacctd.
Although atop's daily restarting mechanism (instead, atopacct will not
restart daily until being restarted deliberately) makes atop reads
from /run/pacct_shadow.d/*.paf again, we still think this should be
repaired.
* Reproduce
Install atop package, get atop and atopacct's pid, check their fds:
# ps aux |grep atop
root 473309 4.7 0.0 37056 15792 ? S<Ls 15:50 0:00 /usr/bin/atop -w /var/log/atop/atop_20211111
root 473377 0.0 0.0 12012 128 ? S< 15:50 0:00 /usr/sbin/atopacctd
root 473742 0.0 0.0 18084 1024 pts/0 S+ 15:50 0:00 grep atop
# ls -l /proc/473309/fd
total 0
lr-x------ 1 root root 64 Nov 11 15:50 0 -> /dev/null
l-wx------ 1 root root 64 Nov 11 15:50 1 -> /var/log/atop/daily.log
l-wx------ 1 root root 64 Nov 11 15:50 2 -> /var/log/atop/daily.log
lr-x------ 1 root root 64 Nov 11 15:50 3 -> /var/cache/atop.d/atop.acct
lrwx------ 1 root root 64 Nov 11 15:50 4 -> socket:[503893125]
l-wx------ 1 root root 64 Nov 11 15:50 5 -> /var/log/atop/atop_20211111
lrwx------ 1 root root 64 Nov 11 15:50 6 -> socket:[503893413]
# ls -l /proc/473377/fd
total 0
lr-x------ 1 root root 64 Nov 11 15:50 0 -> /run/pacct_source
l-wx------ 1 root root 64 Nov 11 15:50 1 -> /run/pacct_shadow.d/0000000000.paf
lrwx------ 1 root root 64 Nov 11 15:50 2 -> socket:[503865811]
l-wx------ 1 root root 64 Nov 11 15:50 3 -> /run/pacct_shadow.d/current
lrwx------ 1 root root 64 Nov 11 15:50 4 -> socket:[503860044]
lrwx------ 1 root root 64 Nov 11 15:50 5 -> socket:[503860045]
* Fix
See the patch in the end :)
2nd. Load atop.default file into the package to make it take effect
* Background
We find that atop.default is not loaded into atop package, but this
file is sometimes used to read environment file in systemd service.
* Fix
See the patch in the end :)
We have tried to fix these two issues via a patch as follows:
**********************The beginning of patch*********************
From 5f962975fa340e75a9a75e94deb8fd8a618ee918 Mon Sep 17 00:00:00 2001
From: Fei Li <lifei....@bytedance.com>
Date: Wed, 10 Nov 2021 20:45:45 +0800
Subject: [PATCH] Fix debian/rules
Two fixes for debian/rules:
- Activate atopacctd before activating the atop daemon, so that atop
can read exited process data from /run/pacct_shadow.d/*.paf instead
of /var/cache/atop.d/atop.acct once installed.
- Load atop.default file into the package to make it take effect.
Signed-off-by: Fei Li <lifei....@bytedance.com>
Co-authored-by: Teng Hu <hute...@bytedance.com>
---
debian/rules | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/debian/rules b/debian/rules
index 7990f9d..8f3e091 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,18 +5,19 @@
override_dh_auto_clean:
dh_auto_clean
- rm -f debian/atop.service debian/atopacct.service debian/atop.init debian/atopacct.init
+ rm -f debian/atop.service debian/atop.default debian/atopacct.service debian/atop.init debian/atopacct.init
rm -f atop atopsar
override_dh_installinit:
- dh_installinit --name=atop
dh_installinit --name=atopacct
+ dh_installinit --name=atop
override_dh_auto_install:
dh_auto_install
make sysvinstall DESTDIR=$(shell pwd)/debian/atop
make systemdinstall DESTDIR=$(shell pwd)/debian/atop
cp atop.service debian/atop.service
+ cp atop.default debian/atop.default
cp atopacct.service debian/atopacct.service
cp atop.init debian/atop.init
cp atopacct.init debian/atopacct.init
--
2.20.1
**********************The end of patch**********************
-- System Information:
Debian Release: 10.5
Architecture: amd64 (x86_64)
Kernel: Linux 5.4
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages atop depends on:
ii libc6 2.28-10
ii libglib2.0-0 2.58.3-2+deb10u2
ii libncurses6 6.1+20181013-2+deb10u2
ii libtinfo6 6.1+20181013-2+deb10u2
ii lsb-base 10.2019051400
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages atop recommends:
ii cron [cron-daemon] 3.0pl1-134+deb10u1
atop suggests no packages.
-- no debconf information
Marc Haber
thanks for helping with atop.
On Thu, Nov 11, 2021 at 04:09:52PM +0800, Fei Li wrote:
> 1st. Should activate atopacctd before activating the atop daemon.
> * Problem
> By reading the source code, to use the preferred way: atopacct daemon,
> we should ensure that atopacctd starts before atop. But the current
> mechanism is that atop starts earlier than atopacctd.
starts earlier than atopacctd? What are the symptoms of the wrong start
oder?
> * Reproduce
> Install atop package, get atop and atopacct's pid, check their fds:
> # ps aux |grep atop
> root 473309 4.7 0.0 37056 15792 ? S<Ls 15:50 0:00 /usr/bin/atop -w /var/log/atop/atop_20211111
> root 473377 0.0 0.0 12012 128 ? S< 15:50 0:00 /usr/sbin/atopacctd
> root 473742 0.0 0.0 18084 1024 pts/0 S+ 15:50 0:00 grep atop
> # ls -l /proc/473309/fd
> total 0
> lr-x------ 1 root root 64 Nov 11 15:50 0 -> /dev/null
> l-wx------ 1 root root 64 Nov 11 15:50 1 -> /var/log/atop/daily.log
> l-wx------ 1 root root 64 Nov 11 15:50 2 -> /var/log/atop/daily.log
> lr-x------ 1 root root 64 Nov 11 15:50 3 -> /var/cache/atop.d/atop.acct
> lrwx------ 1 root root 64 Nov 11 15:50 4 -> socket:[503893125]
> l-wx------ 1 root root 64 Nov 11 15:50 5 -> /var/log/atop/atop_20211111
> lrwx------ 1 root root 64 Nov 11 15:50 6 -> socket:[503893413]
> # ls -l /proc/473377/fd
> total 0
> lr-x------ 1 root root 64 Nov 11 15:50 0 -> /run/pacct_source
> l-wx------ 1 root root 64 Nov 11 15:50 1 -> /run/pacct_shadow.d/0000000000.paf
> lrwx------ 1 root root 64 Nov 11 15:50 2 -> socket:[503865811]
> l-wx------ 1 root root 64 Nov 11 15:50 3 -> /run/pacct_shadow.d/current
> lrwx------ 1 root root 64 Nov 11 15:50 4 -> socket:[503860044]
> lrwx------ 1 root root 64 Nov 11 15:50 5 -> socket:[503860045]
> 2nd. Load atop.default file into the package to make it take effect
/etc/default/atop. This file is different from the atop.default in the
upstream tarball. Debian does set the -R by default.
Please explain why you think the packaging does things wrong.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Marc Haber
On Thu, Nov 11, 2021 at 06:56:33PM +0800, 李菲 wrote:
> wrote:
> I guess the below 'Reproduce' can tell this :) That is, if atop starts
> before
> atopacctd, it will read from /var/cache/atop.d/atop.acct. Instead, if
> atopacctd
> starts earlier, atop will read from /run/pacct_shadow.d/0000000000.paf
> which is generated by atopacctd.
Is this a race condition that only occurs once in a while? I tried it
three times now on a test system and all three times it ended up with
atop reading from the .paf file right after reboot.
Example output:
[2/4438]mh@testsid85:~ $ pgrep '^atop$'; pgrep '^atopacctd$'; sudo ls -la /proc/{$(pgrep '^atop$'),$(pgrep '^atopacctd$')}/fd
348
334
/proc/334/fd:
total 0
dr-x------ 2 root root 0 Nov 24 20:12 .
dr-xr-xr-x 9 root root 0 Nov 24 20:12 ..
lr-x------ 1 root root 64 Nov 24 20:12 0 -> /run/pacct_source
l-wx------ 1 root root 64 Nov 24 20:12 1 -> /run/pacct_shadow.d/0000000000.paf
lrwx------ 1 root root 64 Nov 24 20:12 2 -> 'socket:[12382]'
l-wx------ 1 root root 64 Nov 24 20:12 3 -> /run/pacct_shadow.d/current
lrwx------ 1 root root 64 Nov 24 20:12 4 -> 'socket:[12399]'
lrwx------ 1 root root 64 Nov 24 20:12 5 -> 'socket:[12400]'
/proc/348/fd:
total 0
dr-x------ 2 root root 0 Nov 24 20:12 .
dr-xr-xr-x 9 root root 0 Nov 24 20:12 ..
lr-x------ 1 root root 64 Nov 24 20:12 0 -> /dev/null
lrwx------ 1 root root 64 Nov 24 20:12 1 -> 'socket:[12463]'
lrwx------ 1 root root 64 Nov 24 20:12 2 -> 'socket:[12463]'
lr-x------ 1 root root 64 Nov 24 20:12 3 -> /run/pacct_shadow.d/0000000000.paf
lrwx------ 1 root root 64 Nov 24 20:12 4 -> 'socket:[12504]'
lrwx------ 1 root root 64 Nov 24 20:12 5 -> /var/log/atop/atop_20211124
[3/4439]mh@testsid85:~ $
What am I doing wrong here?
> > > 2nd. Load atop.default file into the package to make it take effect
> >
> > /etc/default/atop. This file is different from the atop.default in the
> > upstream tarball. Debian does set the -R by default.
> >
> > Please explain why you think the packaging does things wrong.
> >
> atop.default file under the source code, the updates will not be synced
> into debian/atop.default under debian/ directory during building.
I would still think this is intended behavior. This originates from the
fact that the support for /etc/default/atop was merged into Upstream
from a series of Debian patches which the Upstream author kindly
accepted (PR #28). We had the defaults file for longer than Upstream had
it, therefore we had our own file.
I see your point though, the next version will take upstream's file,
apply a patch to make Debian's default file from there and install that
to the package. That way, Upstream changes are going to be notice, and
one more patch file doesn't make things any more complex. I have
committed that change to git.
Greetings
Marc
李菲
Hi,
On Thu, Nov 11, 2021 at 06:56:33PM +0800, 李菲 wrote:
> wrote:
> I guess the below 'Reproduce' can tell this :) That is, if atop starts
> before
> atopacctd, it will read from /var/cache/atop.d/atop.acct. Instead, if
> atopacctd
> starts earlier, atop will read from /run/pacct_shadow.d/0000000000.paf
> which is generated by atopacctd.
Is this a race condition that only occurs once in a while? I tried it
three times now on a test system and all three times it ended up with
atop reading from the .paf file right after reboot.
Marc Haber
> On Thu, Nov 25, 2021 at 3:32 AM Marc Haber <mh+debian...@zugschlus.de>
> wrote:
> > On Thu, Nov 11, 2021 at 06:56:33PM +0800, 李菲 wrote:
> > > wrote:
> > > I guess the below 'Reproduce' can tell this :) That is, if atop starts
> > > before
> > > atopacctd, it will read from /var/cache/atop.d/atop.acct. Instead, if
> > > atopacctd
> > > starts earlier, atop will read from /run/pacct_shadow.d/0000000000.paf
> > > which is generated by atopacctd.
> >
> > Is this a race condition that only occurs once in a while? I tried it
> > three times now on a test system and all three times it ended up with
> > atop reading from the .paf file right after reboot.
> >
> You mean reboot the machine? I am wondering why rebooting
> is needed after installing atop.
> I did the following check just
> after installing atop without rebooting the machine. :)
> As for the reboot, I am inclined to the problem is corrected
> after rebooting, mainly due to the "Before=atop.service"
> in atopacct.service file.
李菲
On Thu, Nov 25, 2021 at 03:34:15PM +0800, 李菲 wrote:
> On Thu, Nov 25, 2021 at 3:32 AM Marc Haber <mh+debian...@zugschlus.de>
> wrote:
> > On Thu, Nov 11, 2021 at 06:56:33PM +0800, 李菲 wrote:
> > > wrote:
> > > I guess the below 'Reproduce' can tell this :) That is, if atop starts
> > > before
> > > atopacctd, it will read from /var/cache/atop.d/atop.acct. Instead, if
> > > atopacctd
> > > starts earlier, atop will read from /run/pacct_shadow.d/0000000000.paf
> > > which is generated by atopacctd.
> >
> > Is this a race condition that only occurs once in a while? I tried it
> > three times now on a test system and all three times it ended up with
> > atop reading from the .paf file right after reboot.
> >
> You mean reboot the machine? I am wondering why rebooting
> is needed after installing atop.
It is not. I just tried to reproduce your issue.
> I did the following check just
> after installing atop without rebooting the machine. :)
> As for the reboot, I am inclined to the problem is corrected
> after rebooting, mainly due to the "Before=atop.service"
> in atopacct.service file.
So I need to de- and reinstall atop to reproduce this?
Marc Haber
> In short, build => install => check (no restart) should work.
[15/4605]mh@testsid85:~ $ sudo apt install atop
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
atop
0 upgraded, 1 newly installed, 0 to remove and 5 not upgraded.
Need to get 201 kB of archives.
After this operation, 511 kB of additional disk space will be used.
Get:1 http://debian.debian.zugschlus.de/debian sid/main amd64 atop amd64 2.6.0-2 [201 kB]
Fetched 201 kB in 0s (1.836 kB/s)
Selecting previously unselected package atop.
(Reading database ... 32406 files and directories currently installed.)
Preparing to unpack .../atop_2.6.0-2_amd64.deb ...
Unpacking atop (2.6.0-2) ...
Setting up atop (2.6.0-2) ...
Created symlink /etc/systemd/system/timers.target.wants/atop-rotate.timer → /lib/systemd/system/atop-rotate.timer.
Created symlink /etc/systemd/system/multi-user.target.wants/atop.service → /lib/systemd/system/atop.service.
Created symlink /etc/systemd/system/multi-user.target.wants/atopacct.service → /lib/systemd/system/atopacct.service.
atop-rotate.service is a disabled or a static unit, not starting it.
Processing triggers for man-db (2.9.4-2) ...
[16/4606]mh@testsid85:~ $ sudo ls -la /proc/$(pgrep '^atop$')/fd /proc/$(pgrep '^atopacctd$')/fd
/proc/43189/fd:
total 0
dr-x------ 2 root root 0 Nov 28 21:40 .
dr-xr-xr-x 9 root root 0 Nov 28 21:40 ..
lr-x------ 1 root root 64 Nov 28 21:40 0 -> /run/pacct_source
l-wx------ 1 root root 64 Nov 28 21:40 1 -> /run/pacct_shadow.d/0000000000.paf
lrwx------ 1 root root 64 Nov 28 21:40 2 -> 'socket:[219557]'
l-wx------ 1 root root 64 Nov 28 21:40 3 -> /run/pacct_shadow.d/current
lrwx------ 1 root root 64 Nov 28 21:40 4 -> 'socket:[219561]'
lrwx------ 1 root root 64 Nov 28 21:40 5 -> 'socket:[219562]'
/proc/43192/fd:
total 0
dr-x------ 2 root root 0 Nov 28 21:40 .
dr-xr-xr-x 9 root root 0 Nov 28 21:40 ..
lr-x------ 1 root root 64 Nov 28 21:40 0 -> /dev/null
lrwx------ 1 root root 64 Nov 28 21:40 1 -> 'socket:[219563]'
lrwx------ 1 root root 64 Nov 28 21:40 2 -> 'socket:[219563]'
lr-x------ 1 root root 64 Nov 28 21:40 3 -> /run/pacct_shadow.d/0000000000.paf
lrwx------ 1 root root 64 Nov 28 21:40 4 -> 'socket:[218991]'
l-wx------ 1 root root 64 Nov 28 21:40 5 -> /var/log/atop/atop_20211128
[17/4607]mh@testsid85:~ $
I see that on my system fds 1 and 2 are a socket while yours are files,
and that fd3 is correctly the /run/pacct_shadow.d file.
Am I still doing things wrong here?
Greetings
Marc
Marc Haber
reproduce this by the end of January 2022, I will close this bug.
Greetings
Marc
李菲
--- a/debian/rules
+++ b/debian/rules
@@ -9,8 +9,8 @@ override_dh_auto_clean:
rm -f atop atopsar
override_dh_installinit:
- dh_installinit --name=atopacct
dh_installinit --name=atop
+ dh_installinit --name=atopacct
cp atop.service debian/atop.service | cp atop.service debian/atop.service
cp atop.default debian/atop.default | -----------------------------------------------------------------------------------------
cp atopacct.service debian/atopacct.service | cp atopacct.service debian/atopacct.service
cp atop.init debian/atop.init | cp atop.init debian/atop.init
cp atopacct.init debian/atopacct.init | cp atopacct.init debian/atopacct.init
make[1]: Leaving directory '/root/fei-gitcode/atop' | make[1]: Leaving directory '/root/fei-gitcode/debian-atop-github/atop'
dh_install | dh_install
dh_installdocs | dh_installdocs
dh_installchangelogs | dh_installchangelogs
dh_installman | dh_installman
dh_systemd_enable | dh_installcron
debian/rules override_dh_installinit | debian/rules override_dh_installinit
make[1]: Entering directory '/root/fei-gitcode/atop' | make[1]: Entering directory '/root/fei-gitcode/debian-atop-github/atop'
dh_installinit --name=atop | dh_installinit --name=atop
dh_installinit --name=atopacct | dh_installinit --name=atopacct
make[1]: Leaving directory '/root/fei-gitcode/atop' | make[1]: Leaving directory '/root/fei-gitcode/debian-atop-github/atop'
dh_systemd_start | dh_installsystemd
dh_perl | dh_perl
dh_link | dh_link
dh_strip_nondeterminism | dh_strip_nondeterminism
dh_compress | dh_compress
dh_fixperms | dh_fixperms
dh_missing | dh_missing
-----------------------------------------------------------------------------------------| dh_dwz
dh_strip | dh_strip
dh_makeshlibs | dh_makeshlibs
dh_shlibdeps | dh_shlibdeps
dh_installdeb | dh_installdeb
dh_gencontrol | dh_gencontrol
dh_md5sums | dh_md5sums
dh_builddeb | dh_builddeb
dpkg-deb: building package 'atop' in '../atop_2.6.0+byted3_amd64.deb'. | dpkg-deb: building package 'atop' in '../atop_2.6.0-1_amd64.deb'.
dpkg-deb: building package 'atop-dbgsym' in '../atop-dbgsym_2.6.0+byted3_amd64.deb'. | dpkg-deb: building package 'atop-dbgsym' in '../atop-dbgsym_2.6.0-1_amd64.deb'.
dpkg-genbuildinfo | dpkg-genbuildinfo
dpkg-genchanges >../atop_2.6.0+byted3_amd64.changes | dpkg-genchanges >../atop_2.6.0-1_amd64.changes
dpkg-genchanges: info: including full source code in upload | dpkg-genchanges: info: including full source code in upload
dpkg-source --after-build . | dpkg-source --after-build .
-----------------------------------------------------------------------------------------| dpkg-source: info: using options from atop/debian/source/local-options: --unapply-patches
-----------------------------------------------------------------------------------------| dpkg-source: warning: --unapply-patches is not a valid option for Dpkg::Source::Package::
dpkg-buildpackage: info: full upload; Debian-native package (full source is included) | dpkg-buildpackage: info: full upload; Debian-native package (full source is included)
log-bytedance log-debian
Marc Haber
On Thu, Dec 23, 2021 at 05:31:25PM +0800, 李菲 wrote:
> Yes, this is weird.
> - When I run `dpkg-buildpackage -us -uc` using code from
> https://salsa.debian.org/debian/atop/-/tree/debian/2.6.0-1,
> atopacct service do run earlier than atop. The issue gone.
> - When I run `dpkg-buildpackage -us -uc` using code from
> https://github.com/bytedance/atop/tree/bytedance-internal-v2.6.0+byted3,
> and *revert the execution order of override_dh_installinit[1] in
> debian/rules*, atop service do run earlier than atopacct. The issue exists.
compilation runs?
You will find two stanzas of "Automatically added by
dh_installinit/13.3.3" which are relevant only for systems without
systemd as PID 1, and three stanzas of "Automatically added by
dh_installsystemd/13.3.3". The last one of those is resonsible to start
the daemon after installation. The interesting line of code is
deb-systemd-invoke $_dh_action 'atop-rotate.service' 'atop-rotate.timer' 'atop.service' 'atopacct.service
which will instruct systemd to start all those four services. I am not
sure whether it makes sense for atop to explicitly start the two
atop-rotate units, and I think that systemd decides by itself in which
order the units are started.
I will talk to Upstream whether it makes sense to specify a dependency
in the systemd units.
> I tried to compare with these two branches' compilation process[2], but not
> quite sure which command guarantees atopacct run eariler then atop. Could
> you help to confirm? Thanks.
exchanging the two calls to dh_installinit is not going to change
anything since the generated code is not used on a systemd system.
Marc Haber
> The interesting line of code is
>
> deb-systemd-invoke $_dh_action 'atop-rotate.service' 'atop-rotate.timer' 'atop.service' 'atopacct.service
>
> which will instruct systemd to start all those four services. I am not
> sure whether it makes sense for atop to explicitly start the two
> atop-rotate units, and I think that systemd decides by itself in which
> order the units are started.
atop.service" listed. So, systemd SHOULD take care of starting atopacctd
first before atop is started.
Can you please verify (maybe from syslog?) that the start order is
actually wrong when you encounter the situation of misbehavior?
Just two possibly stupid questions:
(1) are you actually running systemd as PID 1 or did you decide to still
use sysv init?
(2) psacct is installed or not?
李菲
On Thu, Dec 23, 2021 at 07:48:19PM +0100, Marc Haber wrote:
> The interesting line of code is
>
> deb-systemd-invoke $_dh_action 'atop-rotate.service' 'atop-rotate.timer' 'atop.service' 'atopacct.service
>
> which will instruct systemd to start all those four services. I am not
> sure whether it makes sense for atop to explicitly start the two
> atop-rotate units, and I think that systemd decides by itself in which
> order the units are started.
The atopacct unit (systemctl cat atopacct) has an explicit "Before:
atop.service" listed. So, systemd SHOULD take care of starting atopacctd
first before atop is started.
Can you please verify (maybe from syslog?) that the start order is
actually wrong when you encounter the situation of misbehavior?
Dec 24 17:08:22 n198-252-111 atopacctd[27883]: Terminated by signal 15
Dec 24 17:08:22 n198-252-111 systemd[1]: atopacct.service: Succeeded.
Dec 24 17:08:22 n198-252-111 systemd[1]: atop.service: Succeeded.
Dec 24 17:08:22 n198-252-111 systemd[1]: atop-rotate.timer: Succeeded.
Dec 24 17:08:22 n198-252-111 systemd[1]: Stopped Daily atop restart.
Dec 24 17:08:31 n198-252-111 systemd[1]: Started Daily atop restart.
Dec 24 17:08:32 n198-252-111 atopacctd[29508]: Version: 2.6.0+byted3 - 2021/12/23 17:02:33 <gerlof.l...@atoptool.nl>
Dec 24 17:08:32 n198-252-111 atopacctd[29508]: accounting to /run/pacct_source
Just two possibly stupid questions:
(1) are you actually running systemd as PID 1 or did you decide to still
use sysv init?
# systemctl status atop
● atop.service - Atop advanced performance monitor
Loaded: loaded (/lib/systemd/system/atop.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-12-24 17:08:31 CST; 6min ago
(2) psacct is installed or not?
# dpkg -L atop |grep pacct
/etc/init.d/atopacct
/lib/systemd/system/atopacct.service
/usr/sbin/atopacctd
Marc Haber
> On Fri, Dec 24, 2021 at 3:02 AM Marc Haber <mh+debian...@zugschlus.de>
> wrote:
>
> > On Thu, Dec 23, 2021 at 07:48:19PM +0100, Marc Haber wrote:
> > > The interesting line of code is
> > >
> > > deb-systemd-invoke $_dh_action 'atop-rotate.service' 'atop-rotate.timer'
> > 'atop.service' 'atopacct.service
> > >
> > > which will instruct systemd to start all those four services. I am not
> > > sure whether it makes sense for atop to explicitly start the two
> > > atop-rotate units, and I think that systemd decides by itself in which
> > > order the units are started.
> >
> > The atopacct unit (systemctl cat atopacct) has an explicit "Before:
> > atop.service" listed. So, systemd SHOULD take care of starting atopacctd
> > first before atop is started.
> >
> Actually I am not sure whether "before: " only guarantees this
> when the host machine restarts, but not installing packages.
atop's maintainer scripts group all unit starts into a single
transaction, leaving the order of execution to systemd. That's done by
debhelper, and as a package maintainer I am not going to interfere with
that. The best I can do is to help upstream to properly design their
systemd units and probably make code changes to make startup more
robust.
> > Can you please verify (maybe from syslog?) that the start order is
> > actually wrong when you encounter the situation of misbehavior?
> >
> > Run `dpkg --purge atop && dpkg -i ../atop_2.6.0+byted3_amd64.deb`,
> and see the log, just as follows:
> # journalctl | grep atop
>
> Dec 24 17:08:22 n198-252-111 atopacctd[27883]: Terminated by signal 15
>
> Dec 24 17:08:22 n198-252-111 systemd[1]: atopacct.service: Succeeded.
>
> Dec 24 17:08:22 n198-252-111 systemd[1]: atop.service: Succeeded.
>
> Dec 24 17:08:22 n198-252-111 systemd[1]: atop-rotate.timer: Succeeded.
>
> Dec 24 17:08:22 n198-252-111 systemd[1]: Stopped Daily atop restart.
>
> Dec 24 17:08:31 n198-252-111 systemd[1]: Started Daily atop restart.
>
> Dec 24 17:08:32 n198-252-111 atopacctd[29508]: Version: 2.6.0+byted3 -
> 2021/12/23 17:02:33 <gerlof.l...@atoptool.nl>
>
> Dec 24 17:08:32 n198-252-111 atopacctd[29508]: accounting to
> /run/pacct_source
> > (2) psacct is installed or not?
> >
> Yes,
>
> # dpkg -L atop |grep pacct
>
> /etc/init.d/atopacct
>
> /lib/systemd/system/atopacct.service
>
> /usr/sbin/atopacctd
> /usr/share/man/man8/atopacctd.8.gz
李菲
On Fri, Dec 24, 2021 at 05:17:07PM +0800, 李菲 wrote:
> On Fri, Dec 24, 2021 at 3:02 AM Marc Haber <mh+debian...@zugschlus.de>
> wrote:
>
> > On Thu, Dec 23, 2021 at 07:48:19PM +0100, Marc Haber wrote:
> > > The interesting line of code is
> > >
> > > deb-systemd-invoke $_dh_action 'atop-rotate.service' 'atop-rotate.timer'
> > 'atop.service' 'atopacct.service
> > >
> > > which will instruct systemd to start all those four services. I am not
> > > sure whether it makes sense for atop to explicitly start the two
> > > atop-rotate units, and I think that systemd decides by itself in which
> > > order the units are started.
> >
> > The atopacct unit (systemctl cat atopacct) has an explicit "Before:
> > atop.service" listed. So, systemd SHOULD take care of starting atopacctd
> > first before atop is started.
> >
> Actually I am not sure whether "before: " only guarantees this
> when the host machine restarts, but not installing packages.
I surely do hope that this also applies to systemctl transactions.
atop's maintainer scripts group all unit starts into a single
transaction, leaving the order of execution to systemd. That's done by
debhelper, and as a package maintainer I am not going to interfere with
that. The best I can do is to help upstream to properly design their
systemd units and probably make code changes to make startup more
robust.
> > Can you please verify (maybe from syslog?) that the start order is
> > actually wrong when you encounter the situation of misbehavior?
> >
> > Run `dpkg --purge atop && dpkg -i ../atop_2.6.0+byted3_amd64.deb`,
> and see the log, just as follows:
> # journalctl | grep atop
>
> Dec 24 17:08:22 n198-252-111 atopacctd[27883]: Terminated by signal 15
>
> Dec 24 17:08:22 n198-252-111 systemd[1]: atopacct.service: Succeeded.
>
> Dec 24 17:08:22 n198-252-111 systemd[1]: atop.service: Succeeded.
>
> Dec 24 17:08:22 n198-252-111 systemd[1]: atop-rotate.timer: Succeeded.
>
> Dec 24 17:08:22 n198-252-111 systemd[1]: Stopped Daily atop restart.
>
> Dec 24 17:08:31 n198-252-111 systemd[1]: Started Daily atop restart.
>
> Dec 24 17:08:32 n198-252-111 atopacctd[29508]: Version: 2.6.0+byted3 -
> 2021/12/23 17:02:33 <gerlof.l...@atoptool.nl>
>
> Dec 24 17:08:32 n198-252-111 atopacctd[29508]: accounting to
> /run/pacct_source
Is that reproducible?
> > (2) psacct is installed or not?
> >
> Yes,
>
> # dpkg -L atop |grep pacct
>
> /etc/init.d/atopacct
>
> /lib/systemd/system/atopacct.service
>
> /usr/sbin/atopacctd
> /usr/share/man/man8/atopacctd.8.gz
pSacct is a different package, dpkg --list psacct please.
# atop -V
Version: 2.6.0 - 2020/12/21 20:45:10 <gerlof.l...@atoptool.nl>
# dpkg --list psacct
dpkg-query: no packages found matching psacct
Greetings
李菲
> >
> Yes,
>
> # dpkg -L atop |grep pacct
>
> /etc/init.d/atopacct
>
> /lib/systemd/system/atopacct.service
>
> /usr/sbin/atopacctd
> /usr/share/man/man8/atopacctd.8.gz
pSacct is a different package, dpkg --list psacct please.Just make sure if the package's name is called psacct.As after installing v2.6.0 fromI still can not find this package:# atop -V
Version: 2.6.0 - 2020/12/21 20:45:10 <gerlof.l...@atoptool.nl>
# dpkg --list psacct
dpkg-query: no packages found matching psacct
Marc Haber
On Mon, Dec 27, 2021 at 10:57:45AM +0800, 李菲 wrote:
> On Fri, Dec 24, 2021 at 7:18 PM Marc Haber <mh+debian...@zugschlus.de>
> wrote:
> > I surely do hope that this also applies to systemctl transactions.
> > atop's maintainer scripts group all unit starts into a single
> > transaction, leaving the order of execution to systemd. That's done by
> > debhelper, and as a package maintainer I am not going to interfere with
> > that. The best I can do is to help upstream to properly design their
> > systemd units and probably make code changes to make startup more
> > robust.
>
> Sure.
addressed sooner or later. At the moment, do we agree that the proposed
patch, exchanging the two calls to dh_installinit will not help on
systemd systems?
Marc Haber
> After checking, we do not install the `acct` package.
package names from the Red Hat and the Debian universe.
李菲
Hi,
On Mon, Dec 27, 2021 at 10:57:45AM +0800, 李菲 wrote:
> On Fri, Dec 24, 2021 at 7:18 PM Marc Haber <mh+debian...@zugschlus.de>
> wrote:
> > I surely do hope that this also applies to systemctl transactions.
> > atop's maintainer scripts group all unit starts into a single
> > transaction, leaving the order of execution to systemd. That's done by
> > debhelper, and as a package maintainer I am not going to interfere with
> > that. The best I can do is to help upstream to properly design their
> > systemd units and probably make code changes to make startup more
> > robust.
>
> Sure.
I have engaged in discussion with upstream and this issue might be
addressed sooner or later. At the moment, do we agree that the proposed
patch, exchanging the two calls to dh_installinit will not help on
systemd systems?
Marc Haber
(the behavior is different and correct with dh 13, and atop 2.5.0-1 is
the first version that was uploaded with dh 13)
On Tue, Dec 28, 2021 at 10:53:39PM +0800, 李菲 wrote:
> We made another several attempts, and finally find the diff:
> ByteDance's debian/compat is 10, which is too low to behave
> normally. E.g. can not use the "deb-systemd-invoke" feature,
> thus the line: "deb-systemd-invoke $_dh_action 'atop-rotate.service'
> 'atop-rotate.timer' 'atop.service' 'atopacct.service' >/dev/null || true".
> does not occur.
>
> under debian/ remain the same with
> https://salsa.debian.org/debian/atop/-/tree/debian/2.6.0-1),
> everything works well!
flavours of maintainer script snippets. That's a totally plausible
explanatoin, thanks for finding it and documenting it
> We can close this issue. :)