sysstat.service is enabled by default on 24.04 lts

[hideou aoi]

[ Impact ]

The sysstat services are not enabled by default in jammy. They are enabled by default in noble not due to any packaging change, but because the package is now seeded and the services are processed by systemd preset on the first system boot. This is (arguably) a regression.

On package upgrades, the sysstat postinst script checks the debconf setting for the service and calls systemctl to ensure that the service is set to the state declared through debconf. In the seeded pre-installed package in noble, this is set to "disabled". This is done in the postinst AFTER the dh_installsystemd hooks, so the current service "enabled/disabled" status is ignored. This means that, as soon as we upgrade sysstat in a noble (or later) system, the services which are enabled by default will be disabled. this is a bug.

[ Test Plan ]

[ Where problems could occur ]

[ Other info ]

[Original message]

Today i occasionally found that /var/log/sysstat is full with sar data files on my laptop.

I remember i didn't turn this on.

Then

cat /etc/default/sysstat shows ENABLED="false"

But systemctl status sysstat.service shows enabled.

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: sysstat 12.6.1-2
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu3
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Sun May 19 23:07:31 2024
InstallationDate: Installed on 2024-04-26 (23 days ago)
InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240424)
ProcEnviron:
 LANG=en_US.UTF-8
 PATH=(custom, no user)
 SHELL=/bin/bash
 TERM=xterm-256color
 XDG_RUNTIME_DIR=<set>
SourcePackage: sysstat
UpgradeStatus: No upgrade log present (probably fresh install)

[Athos Ribeiro (athos-ribeiro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Would you mind answering these following questions questions:

* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

Until then, since I find it hard to reason whether this is indeed a bug or a local configuration issue, I am marking this bug as incomplete. Please, set it back to new once the information is provided.

[hideou aoi (aoilinux)]

* Is this reproducible?
-- yes, any new install ubuntu 24.04 can see this.

* If so, what specific steps should we take to recreate this bug?
-- dont need any steps, just launch a fresh ubuntu 24.04 you will see it.

If you cat a fresh 24.04's /etc/default/sysstat config file it should show ENABLED="false".
That indicates sysstat.service by default should not run until user change ENABLED="true".

[Athos Ribeiro (athos-ribeiro)]

Thanks for the information, hideou. I believe I understand the issue now.

For noble (24.04), a set of performance engineering tools is installed by default. This set includes sysstat.

This means that starting from 24.04, sysstat is now a seeded package and is included in (some) ubuntu images by default.

Setting the ENABLED value in /etc/default/sysstat to true will not enable the service (that file is used when you want to run sysstat without systemd). In Ubuntu, the package runs through a systemd timer named sysstart-collect.timer.

If you run "systemctl is-enabled sysstat-collect.timer" in your 24.04 fresh install, you will see that the timer is "enabled".

Now we need to understand if this is a regression (or an intended change due to the performance engineering tools effort).

I got a fresh jammy (22.04) install. There, the sysstat package is not seeded, so I needed to install it. After the package installation, the systemd timer "sysstat-collect.timer" was NOT enabled, i.e., we are in fact looking at a potential regression.

There are no changes in the source package (since the package version in 22.04) that would affect the timer enabling/disabling.

I also verified the binary package postinst script from both 22.04 and 24.04 to check if the latter had such changes (some parts of those files are generated during the package build), but there are no relevant changes either.

Next, I tried purging the sysstat package in 24.04 and re-installing it. In this scenario, the service will NOT be enabled by default. It behaves just like the package from jammy (22.04).

Then, I started checking systemd docs and came across systemd's service enablement presets [2]. In short, in a first ever system boot, systemd will enable all installed services unless explicitly told not to. This only happens in the first ever system boot and only for services already present in the system at that time. Since the sysstat systemd services are now (24.04) present during that first boot, they are enabled as part of the preset.

Finally, I also realized that upgrading the sysstat package in noble will disable the service due to the way the postinst is crafted (it sets the service status to whatever the debconf value is (disabled/enabled), and does so after the dh_installsystemd hooks. For the seeded sysstat package, the debconf value is set to its default, which is disabled. To test this, I prepared a local no-change-rebuild of sysstat and upgraded the package in my noble LXD container.

Therefore, even if we find out (or decide) that having the service enabled by default in noble was an intentional change (and this may not be the case), disabling the service after a package upgrade is indeed a bug and should be fixed both in Ubuntu and in Debian.

[1] https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#performance-engineering-tools-23
[2] https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html

[hideou aoi (aoilinux)]

Wow ~ Thank you for your explanation and deep dive.
😘