[atd] Add plugin for the at job scheduler

[suraj-cmd]

cron.py covers cron, but nothing in the tree references atd,
/etc/at.allow, /etc/at.deny, /var/spool/at or atq. An sosreport from a
host using at contains no record of the daemon, its access control files or
its pending queue.

The plugin collects the allow and deny lists, the distribution defaults files,
atq output, and the service status and journal for atd.

Queued jobs under /var/spool/at are not copied. Each is a complete shell
script that embeds the submitting user's environment, which frequently includes
exported credentials. A recursive directory listing is taken instead, which
still shows the pending jobs, their queue, ownership and submission time.

I do not have a system with pending at jobs to test the spool listing against.
The decision not to copy job bodies is the part I would most like a second
opinion on — cron.py does collect /var/spool/cron, so there is an argument
for consistency, but at job files embed the submitter's environment in a way
crontabs do not.

---

Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines

• Is the commit message split over multiple lines and hard-wrapped at 72 characters?
• Is the subject and message clear and concise?
• Does the subject start with [plugin_name] if submitting a plugin patch or a [section_name] if part of the core sosreport code?
• Does the commit contain a Signed-off-by: First Lastname email@example.com?
• Are any related Issues or existing PRs properly referenced via a Closes (Issue) or Resolved (PR) line?
• Are all passwords or private data gathered by this PR obfuscated?

[packit-as-a-service]

Congratulations! One of the builds has completed. 🍾

You can install the built RPMs by following these steps:

• sudo dnf install -y 'dnf*-command(copr)'
• dnf copr enable packit/sosreport-sos-4421
• And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

[arif-ali]

If you can, please test the function of the plugin, just to ensure that it collects the right things please

[suraj-cmd]

@arif-ali Tested on my RHEL-10 VM

# atq
1	Fri Aug 14 01:51:00 2026 a root

# python3 bin/sos report -o atd --batch --build
/var/tmp/sosreport-localhost-2026-08-14-hpeeiht

# ls sos_commands/atd/
atq
journalctl_--no-pager_--unit_atd
ls_-alZR_.var.spool.at
systemctl_status_atd

# cat sos_commands/atd/atq
1	Fri Aug 14 01:51:00 2026 a root

# cat sos_commands/atd/ls_-alZR_.var.spool.at
/var/spool/at:
total 8
drwx------.  3 root root system_u:object_r:user_cron_spool_t:s0       53 Aug 14 00:51 .
drwxr-xr-x. 11 root root system_u:object_r:var_spool_t:s0            121 Feb 21 17:33 ..
-rw-------.  1 root root system_u:object_r:user_cron_spool_t:s0        6 Aug 14 00:51 .SEQ
-rwx------.  1 root root unconfined_u:object_r:user_cron_spool_t:s0 3296 Aug 14 00:51 a0000101c65e85
drwx------.  2 root root system_u:object_r:user_cron_spool_t:s0        6 Jun 30  2025 spool

# find $SOSDIR -path '*spool/at/*' -type f
(no output)

# grep -r "echo hello" $SOSDIR ; echo "exit=$?"
exit=1

What changed since he looked. The units now come from services = ('atd',) rather than explicit add_service_status()/add_journal() calls, per the review on #4429 — and systemctl_status_atd and the journal are still collected, so the tuple does the work.