I've been going over the auditing documentation some.
Auditd doesn't use placeholders like %{process.value}. Based on the list of values:
uid, auid, gid, pid, subj_user, subj_role, subj_type, subj_sen, subj_clr, msgtype, and executable name.
I don't believe logging the parent process name directly in the rule key is possible. I think using "executable name" IS the problem you have with systemctl & reboot.
"You can find the parent process name by using the parent process id (ppid) printed in the audit log." ( which was essentially my first answer, terdon ;-) )
I've discovered you can use ausearch with your original ppid's to find the event where this process was created. It will be logged in the execve system call. That means the PID's are not long gone!
On the same log line as the PPID's, look for type=EXECVE and a list of arguments (a0, a1...) which "make" the command used:
type=EXECVE msg=audit(1622816736.650:123456): argc=3 a0="sh" a1="-c" a2="reboot"
This shows the parent process was a shell (sh), using argument -c running the command (reboot). Now, ausearch and my first suggestion can have a wedding.
#!/bin/bash
# Assuming ausearch command outputs lines with the format id=VAL
for ppid_line in $(your_actual_ausearch_command_here); do
ppid_to_match=$(echo "$ppid_line" | grep -Eo 'id=[0-9]{1,}')
# Extract the process information and commands
process_info=$(sudo cat /var/log/audit/audit.log | grep -i "$ppid_to_match" | grep -Ei 'a0=.*')
echo "$ppid_to_match is: $process_info"
done
exit 0
Your ausearch command retrieves the PPID in the form of id=VAL, isolate id=, then extract the corresponding information which starts with a0=, that lead to the actual command.
