AUSEARCH(8)

✨ AUSEARCH ✨ β€” the query tool from the audit daemon fam

aka ausearch, part of the System Administration Utilities crew πŸ’…


🌸 NAME 🌸

ausearch β€” bestie, it's a tool to query audit daemon logs πŸŽ€


πŸ¦‹ SYNOPSIS πŸ¦‹

ausearch [options]

That's it. That's the whole vibe. Options only, no positional args, we love a clean signature ✨


πŸ’œ DESCRIPTION πŸ’œ

Okay so listen. ausearch is that girl πŸ’… β€” she queries the audit daemon logs for events based on all kinds of different search criteria. And plot twist: she can also take input from stdin, as long as what you're feeding her is the raw log data. Feed her directly, she eats 😌

Here's the thing you need to internalize: each commandline option you give forms an "and" statement. So if you search with -m and -ui, you're saying "return events that have BOTH the requested type AND match the user id given." Both. Not either. AND energy only.

The exception, the one little rebellious moment: the -m and -n options. Multiple record types and multiple nodes are allowed in a search, and that search will return any matching node and record. So those two get to be OR-ish. Special treatment, honestly iconic πŸ‘‘

Also, real talk, you should know this: every single syscall excursion β€” user space into the kernel and back out to user space β€” has one event ID that is unique. Any auditable event triggered during that trip shares this ID so they can all be correlated. One trip, one ID, one found family 🫢

And different parts of the kernel may add supplemental records. Example: an audit event on the syscall "open" will also cause the kernel to emit a PATH record with the file name. ausearch will present all records that make up one event together. Which means β€” and this is important β€” even though you searched for a specific kind of record, the resulting events may still contain SYSCALL records. Surprise guests at the party πŸŽ‰

Also be aware that not all record types have the requested information. For example, a PATH record does not have a hostname or a loginuid. She's doing her best, the data just isn't there 😭


🌈 OPTIONS 🌈

One bullet per flag, bestie. Every single one. Let's go.

  • -a, --event audit-event-id β€” Search for an event based on the given event ID. Messages always start with something like msg=audit(1116360555.329:2401771). The event ID is the number after the ':'. All audit events recorded from one application's syscall have the same audit event ID. A second syscall made by the same application will have a different event ID. That's how they stay unique πŸ’…
  • --arch CPU β€” Search for events based on a specific CPU architecture. If you don't know the arch of your machine but you want to use the 32 bit syscall table and your machine supports 32 bits, you can also use b32 for the arch. Same deal for the 64 bit syscall table β€” you can use b64. You can find your machine's arch by doing 'uname -m' ✨
  • -c, --comm comm-name β€” Search for an event based on the given comm name. The comm name is the executable's name from the task structure. (iykyk)
  • --debug β€” Write malformed events that are skipped to stderr. Not a vibe, but sometimes you gotta see the mess πŸ™ˆ
  • --checkpoint checkpoint-file β€” Checkpoint the output between successive invocations of ausearch such that only events not previously output will print in subsequent invocations.

An auditd event is made up of one or more records. When processing events, ausearch defines events as either complete or in-complete. A complete event is either a single record event or one whose event time occurred 2 seconds in the past compared to the event being currently processed.

A checkpoint is achieved by recording the last completed event output along with the device number and inode of the file the last completed event appeared in checkpoint-file. On a subsequent invocation, ausearch will load this checkpoint data and, as it processes the log files, it will discard all complete events until it matches the checkpointed one. At this point, it will start outputting complete events.

⚠️ Should the file or the last checkpointed event not be found, one of a number of errors will result and ausearch will terminate. See EXIT STATUS for detail. No cap, she will just stop.
  • --eoe-timeout seconds β€” Set the end of event parsing timeout. See end_of_event_timeout in auditd.conf(5) for details. Note that setting this value will override any configured value found in /etc/auditd/auditd.conf. You're the boss now πŸ’…
  • -e, --exit exit-code-or-errno β€” Search for an event based on the given syscall exit code or errno.
  • --escape option β€” This option determines if the output is escaped to make the content safer for certain uses. The options are raw, tty, shell, and shell_quote. Each mode includes the characters of the preceding mode and escapes more characters. That is to say, shell includes all characters escaped by tty and adds more. tty is the default. Ladder of safety, we're climbing it πŸͺœ
  • --extra-keys β€” When the format mode is csv, this option will add a final column with key information</>, if it exists for the event. This would only occur on SYSCALL records which were the result of triggering an audit rule that defines a key.
  • --extra-labels β€” When the format mode is csv, this option will add columns of information about subject and object labels when they exist.
  • --extra-obj2 β€” When the format mode is csv, this option will add columns of information about a second object when it exists. It's rare that a second object is part of a record. Some examples are when a file is renamed from one name to another, or when a device is mounted to a path. Rare queen behavior πŸ‘‘
  • --extra-time β€” When the format mode is csv, this option will add columns of information about broken down time to make subsetting easier.
  • -f, --file file-name β€” Search for an event based on the given filename. The argument will match normal files as well as af_unix sockets.
  • --format option β€” Events that match the search criteria are formatted using this option. The supported formats are: raw, default, interpret, csv, and text.
    • The raw option is described under the --raw command line option.
    • The default option is what you get when no formatting options are passed. It includes one line as a visual separator which indicates the time stamp, and then the records of the event follow.
    • The interpret option is explained under the -i command line option.
    • The csv option outputs the results of the search as a normalized event in comma separated value (CSV) format, suitable for import into analytical programs. ✨ spreadsheet girlies rise ✨
    • The text option turns the event into an English sentence that is easier to understand than other options, but it comes at the expense of loss of detail. In most cases this is perfectly fine since the original event still retains all the original information. Slay, nothing is truly lost πŸ’…
  • -ga, --gid-all all-group-id β€” Search for an event with either effective group ID or group ID matching the given group ID.
  • -ge, --gid-effective effective-group-id β€” Search for an event with the given effective group ID or group name.
  • -gi, --gid group-id β€” Search for an event with the given group ID or group name.
  • -h, --help β€” Help 🫢 (she's helping!)
  • -hn, --host host-name β€” Search for an event with the given host name. The hostname can be either a hostname, a fully qualified domain name, or a numeric network address. No attempt is made to resolve numeric addresses to domain names or aliases. This search typically correlates to the addr or host field of audit events. Also see the --node command which searches the node field. Two different searches, don't mix them up bestie 😌
  • -i, --interpret β€” Interpret numeric entities into text. For example, uid is converted to account name. If the audit logs are unenriched, the conversion is done using the current resources of the machine where the search is being run. So if you have renamed the accounts, or don't have the same accounts on your machine, you could get misleading results. If the logs are enriched, it uses the supplemental data to do the conversion. This allows accurate log reporting even when run on a different machine than the original logs came from. Portable queen ✨
  • -if, --input file-name | directory β€” Use the given file or directory instead of the logs. This is to aid analysis where the logs have been moved to another machine, or only part of a log was saved. The path length is limited to 4064 bytes.
  • --input-logs β€” Use the log file location from auditd.conf as input for searching. This is needed if you are using ausearch from a cron job. Cron girlies, this one's for you πŸ•
  • --just-one β€” Stop after emitting the first event that matches the search criteria. One and done, periodt πŸ’…
  • -k, --key key-string β€” Search for an event based on the given key string.
  • -l, --line-buffered β€” Flush output on every line. Most useful when stdout is connected to a pipe and the default block buffering strategy is undesirable. May impose a performance penalty. Trade-offs, babe 😭
  • -m, --message message-type | comma-sep-message-type-list β€” Search for an event matching the given message type. (Message types are also known as record types.) You may also enter a comma separated list of message types, or multiple individual message types each with its own -m option. There is an ALL message type that doesn't exist in the actual logs β€” it allows you to get all messages in the system. The list of valid message types is long. The program will display the list whenever no message type is passed with this parameter. The message type can be either text or numeric. If you enter a list, there can be only commas and no spaces separating the list. Commas only. No spaces. I'm serious πŸ™ˆ
  • -n, --node node-name β€” Search for events originating from a specific machine. Multiple nodes are allowed, and if any nodes match, the event is matched. This search uses the node field in audit events. Also see the --host command which searches for events related to host information in the audit trail. Again: different search, don't get it twisted πŸ’œ
  • -o, --object SE-Linux-context-string β€” Search for event with tcontext (object) matching the string.
  • -p, --pid process-id β€” Search for an event matching the given process ID.
  • -pp, --ppid parent-process-id β€” Search for an event matching the given parent process ID.
  • -r, --raw β€” Output is completely unformatted. This is useful for extracting records to a file that can still be interpreted by audit tools, or when piping to other audit tools. Raw and unfiltered, just how we like it πŸ”₯
  • -sc, --syscall syscall-name-or-value β€” Search for an event matching the given syscall. You may either give the numeric syscall value or the syscall name. If you give the syscall name, it will use the syscall table for the machine that you are using. Your machine, your table 🫢
  • -se, --context SE-Linux-context-string β€” Search for events with either scontext/subject or tcontext/object matching the given string. Either one, we're not picky ✨

...and bestie, there's more. Part 2 incoming πŸŽ€

  • --session Login-Session-ID β€” want events tied to one specific login session? pass the ID and slay. this attribute gets stamped onto a process the moment a user logs in, so it's the lil string that lets you tie any process back to a particular user login. iconic for tracking a whole session's chaos. πŸ”
  • -su, --subject SE-Linux-context-string β€” find events where the scontext (that's the subject, bestie) matches your string. πŸ’…
  • -sv, --success success-value β€” filter by the success value of an event. legal values are literally just yes and no, no in-between, no vibes. ✨
  • -te, --end [*end-date*] [*end-time*] β€” grab events with time stamps equal to or before the end time you give it. the format of that end time depends on your locale β€” check yours by running date '+%x'. if you skip the date, today is assumed; if you skip the time, now is assumed. use 24-hour clock time, not AM/PM. an example date in the en_US.utf8 locale is 09/03/2009, and an example time is 18:00:00. the date format it accepts is influenced by the LC_TIME environmental variable. 🌸

you can also just use one of these magic words: now, recent, this-hour, boot, today, yesterday, this-week, week-ago, this-month, or this-year. here's the tea on each:

  • now means starting now.
  • recent is 10 minutes ago.
  • boot means the time of day to the second when the system last booted.
  • today means now.
  • yesterday is 1 second after midnight the previous day.
  • this-week means starting 1 second after midnight on day 0 of the week determined by your locale (see localtime).
  • week-ago means 1 second after midnight exactly 7 days ago.
  • this-month means 1 second after midnight on day 1 of the month.
  • this-year means the 1 second after midnight on the first day of the first month.
  • -ts, --start [*start-date*] [*start-time*] β€” grab events with time stamps equal to or after the start time. same deal: format depends on your locale, check it with date '+%x'. omit the date and today is assumed; omit the time and midnight is assumed. 24-hour clock only, no AM/PM shenanigans. example date in en_US.utf8 is 09/03/2009, example time is 18:00:00. again, LC_TIME influences the accepted date format. πŸ’œ

magic words available here: now, recent, this-hour, boot, today, yesterday, this-week, week-ago, this-month, this-year, or checkpoint.

  • boot means the time of day to the second when the system last booted.
  • today means starting at 1 second after midnight.
  • recent is 10 minutes ago.
  • yesterday is 1 second after midnight the previous day.
  • this-week means starting 1 second after midnight on day 0 of the week determined by your locale (see localtime).
  • week-ago means starting 1 second after midnight exactly 7 days ago.
  • this-month means 1 second after midnight on day 1 of the month.
  • this-year means the 1 second after midnight on the first day of the first month.

and checkpoint? okay so this one is the rescue mission 🫢 β€” it means ausearch will use the timestamp found inside a valid checkpoint file, and it ignores the recorded inode, device, serial, node and event type that are also chilling in that checkpoint file. basically it's the recovery move for when an ausearch run with a checkpoint option fails with an exit status of 10, 11 or 12. it could be used in a shell script something like:

ausearch --checkpoint /etc/audit/auditd_checkpoint.txt -i
_au_status=$?
if test ${_au_status} -eq 10 -o ${_au_status} -eq 11   -o ${_au_status} -eq 12
then
  ausearch --checkpoint /etc/audit/auditd_checkpoint.txt --start checkpoint -i
fi
  • -tm, --terminal terminal β€” match an event with the given terminal value. fun fact: some daemons like cron and atd use the daemon name as the terminal, so don't be confused when you see that. πŸ‘‘
  • -ua, --uid-all all-user-id β€” search for an event with either the user ID, the effective user ID, or the login user ID (auid) matching the user ID you gave. all three, one flag, no cap. πŸ”₯
  • -ue, --uid-effective effective-user-id β€” match events with the given effective user ID.
  • -ui, --uid user-id β€” match events with the given user ID.
  • -ul, --loginuid login-id β€” match events with the given login user ID. ⚠️ important caveat: all entry point programs that are PAMified need to be configured with pam_loginuid required for the session, otherwise searching on loginuid (auid) won't be accurate. periodt.
  • -uu, --uuid guest-uuid β€” match an event with the given guest UUID. πŸ¦‹
  • -v, --version β€” prints the version and dips. short and sweet. ✨
  • -vm, --vm-name guest-name β€” match an event with the given guest name.
  • -w, --word β€” forces string based matches to match the whole word. this category of matches includes: filename, hostname, terminal, keys, and SE Linux context. no partials, no crumbs. πŸ’…
  • -x, --executable executable β€” match an event with the given executable name.

🚦 EXIT STATUS 🚦

  • 0 β€” if OK. we love to see it. πŸ’–
  • 1 β€” if nothing found, or argument errors, or minor file access/read errors. it's giving "no results or something's a lil off". 😭
  • 10 β€” invalid checkpoint data found in checkpoint file.
  • 11 β€” checkpoint processing error.
  • 12 β€” checkpoint event not found in matching log file.

πŸ“ NOTE πŸ“

the boot time option is a convenience function and it has limitations, bestie. the time it calculates is based on time now minus /proc/uptime. if, after boot, the system clock has been adjusted β€” perhaps by ntp β€” then that calculation may be wrong. in that case you'll need to fully specify the time yourself. πŸ™ˆ

you can check the time it would use by running:

date -d "`cut -f1 -d. /proc/uptime` seconds ago"

🌈 EXAMPLES 🌈

search for a specific user:

# ausearch --start today --loginuid john -i

check the SELinux log for any denials today:

# ausearch --start today -m avc -i

output any recent SELinux log:

# ausearch -m avc,user_avc,selinux_err,user_selinux_err -i -ts recent

output logs in text format:

# ausearch --start today --format text

output TTY events interpreted and shell escaped:

# ausearch --start today -m TTY -i --escape shell_quote

πŸ‘€ SEE ALSO πŸ‘€

auditd(8), auditd.conf(5), aureport(8), pam_loginuid(8).


and that's the whole page, bestie β€” you ate that. πŸŽ€ this one came from Red Hat, dated March 2026, and it's the AUSEARCH(8) manual page, part two of two. go forth and grep responsibly. πŸ’–βœ¨πŸ¦‹

πŸ“¦ where this page comes from