System activity reports

I’ve been having the odd slowdown and needed to check the sar(1) reports. The sa1 and sa2 scripts don’t seem to be installed into cron by default. It’s odd since sa1 is clearly running (I’m seeing the expected /var/log/sa/saDD files) but there were only a couple of sar reports, and those from last month.

It’s not a biggy, I’ve just dropped the following into /etc/cron.daily and all seems well. Is this a bug that needs reporting? It’s just a bit annoying when old friends(?) go missing!

# cat /etc/cron.daily/sa2 
/usr/lib64/sa/sa2 -A &

I don’t seem to have sysstat in any “AL8”. (Then again, early CL8 did not install rsyslog either.)
CentOS 7 had sysstat in group base, so almost always installed.

[CL7]$ repoquery --groupmember sysstat

[AL8] dnf -q repoquery --groupmember sysstat

CentOS 7 had a cron and a systemd-service.
AlmaLinux 8 has three systemd-services. I bet some are not enabled by default.

[CL7]$ rpm -ql sysstat | grep -E "cron|systemd"

[AL8] dnf -q repoquery -l sysstat | grep -E "cron|systemd"

Thanks, I should have guessed. The usual answer to where has XYZ gone is into Potty’s black hole. :frowning_face: Why wreck a perfectly good working system? I’ve been using sa/sar since the turn of the century.

Still doesn’t work though, so I’ll leave my retrofix in place.

Interesting. Did install sysstat to see what I get:

$ systemctl status sysstat-collect.timer
● sysstat-collect.timer - Run system activity accounting tool every 10 minutes
   Loaded: loaded (/usr/lib/systemd/system/sysstat-collect.timer; enabled; vendor preset: disabled)
   Active: inactive (dead)
  Trigger: n/a

$ systemctl status sysstat-summary.timer
● sysstat-summary.timer - Generate summary of yesterday's process accounting
   Loaded: loaded (/usr/lib/systemd/system/sysstat-summary.timer; enabled; vendor preset: disabled)
   Active: inactive (dead)
  Trigger: n/a

$ systemctl list-timers --all
NEXT                          LEFT          LAST                          PASSED    UNIT                         ACTIVATES
Fri 2021-10-22 20:13:09 EEST  43min left    n/a                           n/a       dnf-makecache.timer          dnf-makecache.service
Sat 2021-10-23 00:00:00 EEST  4h 30min left Fri 2021-10-22 19:13:50 EEST  15min ago unbound-anchor.timer         unbound-anchor.service
Sat 2021-10-23 19:28:53 EEST  23h left      Fri 2021-10-22 19:28:53 EEST  20s ago   systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
n/a                           n/a           n/a                           n/a       sysstat-collect.timer        sysstat-collect.service
n/a                           n/a           n/a                           n/a       sysstat-summary.timer        sysstat-summary.service

5 timers listed.

Both timers appear to be enabled. (I did not start sysstat service.)

$ cat /usr/lib/systemd/system/sysstat-summary.timer
# /usr/lib/systemd/system/sysstat-summary.timer
# (C) 2014 Tomasz Torcz <>
# sysstat-11.7.3 systemd unit file:
#        Triggers daily summary generation.
#        Activates sysstat-summary.service

Description=Generate summary of yesterday's process accounting



$ cat /usr/lib/systemd/system/sysstat-collect.timer
# /usr/lib/systemd/system/sysstat-collect.timer
# (C) 2014 Tomasz Torcz <>
# sysstat-11.7.3 systemd unit file:
#        Activates activity collector every 10 minutes

Description=Run system activity accounting tool every 10 minutes



One has *:00/10 and the other 00:07:00 schedule. Both should fire every day.
When they fire, they should run the respective services:
/usr/lib64/sa/sa1 1 1 and /usr/lib64/sa/sa2 -A

You haven’t got anything with?

journalctl -u sysstat-summary.service

but got something with:

journalctl -u sysstat-collect.service
# journalctl -u sysstat-summary.service
-- Logs begin at Fri 2021-10-22 09:20:04 BST, end at Fri 2021-10-22 20:04:29 BST. --
-- No entries --

but then if it fires at 00:07:00 I’ll be asleep and the computer is shut down. Why can’t they just leave things that aren’t broken alone! It should run any time between 00:00:01 and 23:58 (to allow time for completion) so the obvious place is where it has always been cron.daily. Ah well, thanks for your help, your’re not the power mad idiot that landed this on us after all.

The cron should act like OnCalendar of systemd-timer – sans leeway. Isn’t it the anacron that does the magic for you?

I could not figure out, whether systemd can mimic anacron or not. Cron, Anacron and the system.d timers – Angelo d'Elia IT Consulting and Training – Warsaw, Poland

Yes, anacron drives /etc/cron.daily/*, /etc/cron.weekly/* and /etc/cron.monthly/*. It was introduced specifically to deal with computers that are not always on.

Anyhow, thanks guys. I’ll leave my patch in place and get back to discovering why the %iowait went from a few % up to over 50% for a couple of periods yesterday. I’ve a feeling that SELinux was swamping the audit system and making everything unresponsive. I saw the disk average wait time exceed 5s at one point - nasty.

Follow up note. I was taken into hospital on Saturday, and so my machine has run continuously from then. Just as @jlehtone said, the sar report was created in the wee small hours.

@MartinR Get well real soon!

Thanks Jack. I’ve recovered from the acute incident, but now need a bit of fairly routine outpatient surgery on my heart in the next few weeks.