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 ** Changed in: sysstat (Ubuntu) Status: Incomplete => Triaged ** Changed in: sysstat (Ubuntu) Importance: Undecided => High ** Tags added: server-todo -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2066117 Title: sysstat.service is enabled by default on 24.04 lts To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysstat/+bug/2066117/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
