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
#!/bin/bash
/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.
Thanks, I should have guessed. The usual answer to where has XYZ gone is into Potty’s black hole. 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 <tomek@pipebreaker.pl>
#
# sysstat-11.7.3 systemd unit file:
# Triggers daily summary generation.
# Activates sysstat-summary.service
[Unit]
Description=Generate summary of yesterday's process accounting
[Timer]
OnCalendar=00:07:00
[Install]
WantedBy=sysstat.service
$ cat /usr/lib/systemd/system/sysstat-collect.timer
# /usr/lib/systemd/system/sysstat-collect.timer
# (C) 2014 Tomasz Torcz <tomek@pipebreaker.pl>
#
# sysstat-11.7.3 systemd unit file:
# Activates activity collector every 10 minutes
[Unit]
Description=Run system activity accounting tool every 10 minutes
[Timer]
OnCalendar=*:00/10
[Install]
WantedBy=sysstat.service
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
# 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.
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.
Why wreck a perfectly good working system? I’ve been using sa/sar since the turn of the century.