3

We had sar working on our Ubuntu server, but did some work on the server and now it's stopped logging to the day's logfile.

sar -b 5 5

This indicates that sar is alive, and monitoring data, but

ubuntu@testing:/var/log/sysstat$ sar

outputs:

Linux 5.4.0-1063-azure (server)     02/22/22    _x86_64_    (4 CPU)

10:22:05     LINUX RESTART  (4 CPU)

10:22:46     LINUX RESTART  (4 CPU)

10:24:25     LINUX RESTART  (4 CPU)

16:34:04     LINUX RESTART  (4 CPU)

The cron and the sysstat config have not changed.

*/1 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1

Why isn't stats data getting added to the log?

strangerpixel
  • 133
  • 3

2 Answers2

3

Comparing 2 installations, one is Debian 11 that was upgraded from Debian 10, and the other is a fresh Debian 11, both using systemd:

  • on Debian 10 then 11, I already have sysstat-collect and sysstat-summary enabled
  • on fresh Debian 11, I don't

So, if you're using systemd, you should reconfigure sysstat that will run through systemd and not through crontab:

dpkg-reconfigure sysstat

Select "Yes".

Editing /etc/default/sysstat directly (as I did until now) is a mistake: it doesn't update systemd files.

Note that you'll see /etc/default/sysstat updated to ENABLED="true", but the cron won't run anymore (systemd will trigger it as expected).

You can check everything is fine using:

systemctl status sysstat-collect.timer
systemctl status sysstat-summary.timer

which should reply with «Active: active (waiting)»

Yvan
  • 412
  • 4
  • 9
0

I had the same problem, and in my case (Debian 11), one solution was changing debian-sa1 to sa1 in the cron file since the debian-sa1 will be exited when the system is shipped with being systemd enable.

After applying this hack, the cron config file of sysstat would be like this (/etc/cron.d/sysstat):

...
*/1 * * * * root command -v sa1 > /dev/null && sa1 1 1
...

EDIT:

As Yvan explained, to run sysstat by systemd instead of cron, we can start sysstat-collect.timer and sysstat-summary.timer timers manually, in case they are inactive:

systemctl start sysstat sysstat-collect.timer sysstat-summary.timer

And also enable them to be automatically started by system boot-up:

systemctl enable sysstat sysstat-collect.timer sysstat-summary.timer

Finally and after explaining these hacks, maybe the best solution, in this case, is to reconfigure sysstat to be run with systemd instead of cron, which is greatly described in this answer by Yvan.

armanexplorer
  • 11
  • 2
  • Looking at the debian-sa1 script, it seems that it's returning nothing if `systemd` is enabled. So you may run it through `systemd` and not through cron anymore. – Yvan Nov 16 '22 at 08:00
  • 1
    @Yvan You are completely right about the `debian-sa1` script, although it was strangely the default state of the delivered VPS. It seems I could have started two related service timers (`sysstat-collect.timer` and `sysstat-summary.timer`) manually, while they were supposed to be triggered by starting the `sysstat` service (according to the `sysstat.service` code). I will add more details to this answer to cover this as an alternative solution. – armanexplorer Apr 20 '23 at 15:52
  • 1
    As the follow-up to the previous comment, the reason that `sysstat-collect.timer` and `sysstat-summary.timer` have not been triggered is the fact that `systemd` runs the `[install]` section of a service (in this case, `sysstat`) only if we make the service `enable`, and in this case, the mentioned services are triggered there. So, we could only enable `sysstat`. – armanexplorer Apr 20 '23 at 20:02
  • I think that `dpkg-reconfigure sysstat` does exactly that: enabling the service, which in turns enables both timers. So it seems that one way or the other is fine. But editing `/etc/` or cron files is wrong. I've learned it the hard way. Same as `myservice.service.d/override.conf` for systemd, which is very powerful. – Yvan Apr 21 '23 at 17:04
  • 1
    I agree with you. Editing the `sysstat` cron file is not neat and only is a hack around. So, `dpkg-reconfigure sysstat` seems to be the best approach to resolve this problem. – armanexplorer Apr 21 '23 at 17:47