Linux Audit Framework · Event SYSCALL
auditd type=SYSCALL: the record everything else hangs off
A single audited action produces several lines that all share one event ID. SYSCALL is the spine of that group — it says which kernel call was made, whether it worked, and by whom, and every other line in the event describes some part of it.
Also written as type=SYSCALLauditd SYSCALL recordaudit.log syscall entryauditd exit success=no
- How oftenFires constantly
- Vendor calls itaudit
- Logaudit
What it means for you
For an analyst
The thing to internalise is that an auditd event is a group, not a line. The msg=audit(epoch:serial) value is the join key, and ausearch reassembles groups where grep gives you fragments — which is why grepping audit.log directly produces such confusing results. Two field traps. success=no means the syscall returned an error, not that a security control blocked it; a permission denial and a missing file look identical at this level. And exit is the raw return: negative values are negated errno codes, so exit=-13 is EACCES and exit=-2 is ENOENT, which is often the most informative field in the entire record.
The fields that decide it
Everything else in the log line is context.
- msg=audit(epoch:serial)
- The event identifier shared by every record in the group. The serial is what ties PATH, CWD, EXECVE and PROCTITLE to this SYSCALL.
- syscall
- The numeric system call, which ausearch -i translates to a name. Numbers differ by architecture, so never compare raw numbers across platforms.
- success and exit
- Whether it worked and what it returned.
-
success=yesThe call completed. exit typically holds a file descriptor or a byte count. -
success=no exit=-13EACCES — permission denied. Someone tried to reach something they were not allowed to. -
success=no exit=-2ENOENT — the file did not exist. Very common and usually uninteresting on its own. -
success=no exit=-1EPERM — the operation was not permitted, which usually means a missing capability rather than file permissions. - auid
- The login UID, set when the session was created and unchanged by su or sudo. A value of 4294967295 means no login session — a daemon rather than a person.
- uid, euid, suid, fsuid
- The effective identity at the time of the call. euid of 0 with a non-zero auid is exactly the shape of a user acting as root.
- key
- The rule key from the audit rule that caused this to be logged. Without one you cannot tell which of your rules fired.
- comm and exe
- The short command name and the full path of the binary. comm is truncated to 16 characters and is trivially set by the process itself; exe is the one to trust.
Common questions
Why does one action produce several lines in audit.log?
Because auditd splits an event across record types: SYSCALL for the call itself, CWD for the working directory, one PATH per file involved, EXECVE for arguments, PROCTITLE for the command line. They all carry the same msg=audit(timestamp:serial) value. Use 'ausearch' rather than grep — it reassembles the group, whereas grep hands you disconnected fragments that are genuinely hard to interpret.
What does success=no mean in an auditd SYSCALL record?
That the system call returned an error, and nothing more. It does not mean a security control intervened. A file that does not exist, a permission denial, and a bad argument all produce success=no. The exit field distinguishes them: it holds the negated errno, so -13 is permission denied and -2 is no such file.
What is the difference between auid and uid?
uid is who the process is running as right now; auid is who logged in to start the session and does not change when they use su or sudo. That makes auid the field that survives privilege escalation and the only reliable way to attribute root activity to a person. An auid of 4294967295 means there was no login session at all, which identifies daemons and boot-time activity.
Why can I not tell which audit rule produced a record?
Because the rule was written without a key. Adding '-k somekey' to each rule stamps every resulting record with it, so you can tell which rule fired and filter with 'ausearch -k somekey'. Retrofitting keys onto an existing rule set is one of the highest-value changes you can make to an audit configuration.
Read next
- Read alongside auditd type=PATH: which file the operation actually touched The PATH records attached to this event, which name the files the syscall touched.
- Read alongside auditd EXECVE: a command was executed The EXECVE record, which carries the full argument list for an execution.
- The equivalent of auditd type=CONFIG_CHANGE: the audit rules themselves changed Changes to the audit rules themselves, which determine what produces SYSCALL records at all.
- The equivalent of auditd USER_AUTH: an authentication attempt was recorded Authentication records, which are generated by PAM rather than by syscall rules.
- Usually comes before su: someone switched to another account successfully A user becoming root, after which auid is the only thing still linking activity back to them.
Mentioned by
Vendor documentation
Last reviewed 6 September 2026