sa1 is the wrapper behind every sysstat daily file, quietly called every ten minutes by a timer you may never have looked at. You will collect one or more system activity samples with it, check the resulting binary data file, and work out which scheduler is already running it. The examples use sysstat 12.6.1 on this machine. Allow about fifteen minutes for a first collection and verification. It writes binary data under /var/log/sysstat, so the collection step normally needs elevated privileges.
sa1 is a shell wrapper around sadc, installed at /usr/lib/sysstat/sa1 rather than anywhere an interactive user's PATH normally searches. Check the path and version before putting it into a service or script:
$ test -x /usr/lib/sysstat/sa1 && echo 'sa1 is executable'
sa1 is executable
$ dpkg-query -W -f='${Package} ${Version}\n' sysstat
sysstat 12.6.1-2
$ /usr/lib/sysstat/sadc -V
sysstat version 12.6.1The exact package revision will vary by host. The absolute path matters in cron and systemd units, where an interactive shell's PATH is not a safe assumption.
Read the installed units and cron file before adding anything of your own. Running two collectors against the same daily file can cause contention or duplicate samples. Both checks below are read-only:
$ systemctl cat sysstat-collect.timer sysstat-collect.service
$ sed -n '1,120p' /etc/cron.d/sysstatOn this installation, systemd schedules /usr/lib/sysstat/sa1 1 1 every ten minutes. The cron file also contains a Debian helper, but that helper exits when systemd is running, and it honours ENABLED in /etc/default/sysstat too. Do not create a second root crontab entry until you know which mechanism is actually active.
Checkpoint: If systemctl is-enabled sysstat.service or systemctl list-timers sysstat-collect.timer shows an active setup, use that existing schedule. Enabling or editing a scheduler is a separate operational change and may need a maintenance decision.
For a controlled test, ask sa1 for one sample after a one-second interval. This appends a record to the current standard daily file, and because it changes system accounting data, review the target first and use sudo only for this operation:
$ sudo /usr/lib/sysstat/sa1 1 1
$ printf 'sa1 exit status: %s\n' "$?"
sa1 exit status: 0sadc 1 1 for a normal single sample.--boot here. It writes a dummy record marking a counter restart, not an ordinary measurement.Checkpoint: Identify the file changed most recently without opening it as text:
$ sudo find /var/log/sysstat -maxdepth 1 -type f -name 'sa*' -printf '%TY-%Tm-%Td %TH:%TM %s %p\n' | sort | tail -5Daily files normally use names such as sa26, the day of the month. If sysstat is configured for long names, expect saYYYYMMDD instead. These files are binary, so a successful file result tells you more than cat ever will.
Most kernel data is collected by default, but the optional activities have to be requested. The DISK keyword collects block-device statistics, using the documented sa1 form below:
$ sudo /usr/lib/sysstat/sa1 1 1 -S DISK
$ printf 'sa1 exit status: %s\n' "$?"
sa1 exit status: 0XDISK extends this with partition and filesystem statistics on supported kernels.ALL requests every optional activity sadc lists.XALL also includes the extensions. More metrics mean bigger records, so select only what your reports actually need.There is a subtle file-level default worth knowing: activities already present in an existing data file win over a later -S selection when records are appended. Choose your optional metrics when the file is first established, and keep a consistent collection policy; a later -S DISK does not retroactively add disk counters to older records.
Use sar to interpret the binary file. Without a filename it picks the current standard file; for disk activity, ask for the disk report:
$ sar -d
Linux ...
... DEV tps rkB/s wkB/s ...The header and rows depend on the kernel, devices and samples available. If the current standard file is not present, specify an existing file explicitly after checking its name:
$ sudo ls -l /var/log/sysstat/sa*
$ sar -d -f /var/log/sysstat/saDDReplace saDD with the actual path, such as sa26, and do not type the literal placeholder. An error saying the file cannot be opened usually means collection is disabled, the date-specific filename differs, or no sample has been written yet. Rerunning sar with random flags will not fix any of those.
--rotate writes a record into the previous day's standard file, meant to run shortly after midnight so the final interval before midnight is covered:
$ sudo /usr/lib/sysstat/sa1 --rotate
$ printf 'rotation exit status: %s\n' "$?"
rotation exit status: 0Use --rotate iso when your standard files are configured with ISO date names. This is a state-changing operation on the accounting file, not a report command, so let the package's existing timer or cron arrangement handle it when one is installed. If you add a custom schedule, remove it again before returning to the package-managed one, and check that only one rotation job survives.
System transitions need markers, not a normal timed sample. --boot records that counters restarted from zero; --sleep records entry to or exit from suspend or hibernation:
$ sudo /usr/lib/sysstat/sa1 --boot
$ sudo /usr/lib/sysstat/sa1 --sleep suspend
$ sudo /usr/lib/sysstat/sa1 --sleep resumeDo not use these as substitutes for routine collection: they add comments or dummy records that help sar make sense of gaps and counter resets. On a managed system, the installed service and sleep integration normally call these hooks for you.
Warning: do not edit /var/log/sysstat files by hand or delete them to make a report work. Removing historical binary data is irreversible. If a test produced an unwanted sample, leave it in place and note the time; the following valid samples still preserve a truthful collection history. If a file is damaged or incompatible, stop the competing collector first and take a backup before any repair. The -F option belongs to sadc's lower-level interface and can truncate an unknown output file, so it is not a routine sa1 recovery step.
Recovery: If collection fails, check sudo test -d /var/log/sysstat, sudo test -r /proc/stat, and the service log with journalctl -u sysstat-collect.service. A non-zero status, a missing kernel interface, a disabled package setting and a lock conflict are four different failures: diagnose the one you actually have before touching permissions or adding sudo to a scheduler.
sa1 path are confirmed.sar.