auditd problem with type=OBJ_PID

[doc dodo]

Hello,

My Wazuh-agent sends logs auditd from local audit.log

type=OBJ_PID msg=audit(1781014393.836:247151): opid=134117 oauid=0 ouid=0 oses=6656 ocomm="yes"OAUID="root" OUID="root"

But Wazuh server recieve log only from  /var/log/syslog:

2026 Jun 09 17:17:24 (auditd-test) any->/var/log/syslog 2026-06-09T14:17:23.790427+00:00 ubuntu audispd: type=OBJ_PID msg=audit(1781014643.788:247311): opid=134147 oauid=0 ouid=0 oses=6656 ocomm="yes" OAUID="root" OUID="root"

Because of this, the decoder does not decode the received log.

The following block is specified in the agent settings :

  <localfile>
    <log_format>audit</log_format>
    <location>/var/log/audit/audit.log</location>
  </localfile>

Why log with  type=OBJ_PID recieve only from  /var/log/syslog, but not from  /var/log/audit/audit.log ?

[Olamilekan Abdullateef Ajani]

Hello,

Made some research on this and the issue is that auditd is forwarding OBJ_PID events to syslog via audispd instead of writing them directly to /var/log/audit/audit.log.

This happens because:
audispd / af_unix plugin is routing events to syslog
The audispd dispatcher intercepts audit events and forwards them to syslog.

This can be confirmed by checking the file:
/etc/audisp/plugins.d/syslog.conf has active = yes
/etc/audit/plugins.d/syslog.conf has active = yes (auditd ≥ 3.x)

The audispd: prefix in your log already confirms the syslog plugin is re-emitting the event as I initially suggested.

Another thing is that OBJ_PID is a secondary/associated record type that is never emitted alone. It is part of a multi-record audit event (like attached to a SYSCALL record). If Wazuh reads audit.log and only receives the OBJ_PID line without its parent event, the decoder will fail because the context is missing.

What you can do in this case is to verify audit.log is actually receiving the events: cat /var/log/audit/audit.log | grep OBJ_PID
If nothing appears there but it shows in syslog, the plugin is definitely intercepting before the file write.

Then you can disable the syslog audisp plugin and check and disable the plugin so events stop being duplicated to syslog:

sudo nano /etc/audisp/plugins.d/syslog.conf (for older auditd)

sudo nano /etc/audit/plugins.d/syslog.conf (For newer auditd )

Then set active = no
Restart auditd
sudo systemctl restart auditd

Please let me know what you find and if you require further assistance.

[doc dodo]

Hello, 

If set  active = no then string type=OBJ_PID  is present in the file  /var/log/audit/audit.log , but it is not  in  archive.log on the Wazuh server  .

вторник, 9 июня 2026 г. в 19:44:58 UTC+3, Olamilekan Abdullateef Ajani:

[doc dodo]

I find problem. In the archive.log string  type=OBJ_PID  merges with the previous line:

type=SYSCALL msg=audit(1781074418.588:398989): arch=c000003e syscall=62 success=yes exit=0 a0=24fd1 a1=9 a2=0 a3=724c067b1fc0 items=0 ppid=145128 pid=145185 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=7819 comm="bash" exe="/usr/bin/bash" subj=unconfined key="stop_process"ARCH=x86_64 SYSCALL=kill AUID="root" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=OBJ_PID msg=audit(1781074418.588:398989): opid=151505 oauid=0 ouid=0 oses=7819 ocomm="yes"OAUID="root" OUID="root" type=PROCTITLE msg=audit(1781074418.588:398989): proctitle=737368643A20726F6F74407074732F34

среда, 10 июня 2026 г. в 09:32:28 UTC+3, doc dodo:

[Olamilekan Abdullateef Ajani]

Hello,

So the logs are now correctly arriving from the correct source now. Thank you for the feedback.

Before we troubleshoot this further, can you confirm on the agent server where the log was recorded from if it merges same way in the  /var/log/audit/audit.log  file too?

Please let me know

[doc dodo]

Hello,

/var/log/audit/audit.log exists 2 strings:

type=SYSCALL msg=audit(1781074418.588:398989): arch=c000003e syscall=62 success=yes exit=0 a0=24fd1 a1=9 a2=0 a3=724c067b1fc0 items=0 ppid=145128 pid=145185 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=7819 comm="bash" exe="/usr/bin/bash" subj=unconfined key="stop_process"ARCH=x86_64 SYSCALL=kill AUID="root" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" 

type=OBJ_PID msg=audit(1781074418.588:398989): opid=151505 oauid=0 ouid=0 oses=7819 ocomm="yes"OAUID="root" OUID="root" type=PROCTITLE msg=audit(1781074418.588:398989): proctitle=737368643A20726F6F74407074732F34

archive.log exists 1 string:

type=SYSCALL msg=audit(1781074418.588:398989): arch=c000003e syscall=62 success=yes exit=0 a0=24fd1 a1=9 a2=0 a3=724c067b1fc0 items=0 ppid=145128 pid=145185 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=7819 comm="bash" exe="/usr/bin/bash" subj=unconfined key="stop_process"ARCH=x86_64 SYSCALL=kill AUID="root" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=OBJ_PID msg=audit(1781074418.588:398989): opid=151505 oauid=0 ouid=0 oses=7819 ocomm="yes"OAUID="root" OUID="root" type=PROCTITLE msg=audit(1781074418.588:398989): proctitle=737368643A20726F6F74407074732F34

среда, 10 июня 2026 г. в 16:50:12 UTC+3, Olamilekan Abdullateef Ajani:

[Olamilekan Abdullateef Ajani]

Hello,

From what you shared, this confirms the merging is happening on the agent side, even in audit.log on the agent, line 2 already has OBJ_PID and PROCTITLE merged together on a single line. auditd itself wrote them that way.
But what archive.log on the Wazuh server shows is that all 3 record types (SYSCALL + OBJ_PID + PROCTITLE) are on one line, because the Wazuh agent's log_format audit collector joins lines that share the same event ID (398989) before shipping to the server. Which explains why you see it that way.

We can investigate why they are concantenated, please check the auditd dispatcher config:

cat /etc/audit/auditd.conf | grep -E "dispatcher|write_logs|log_format"

Also check if af_unix plugin is active:

cat /etc/audit/plugins.d/af_unix.conf
OR

cat /etc/audisp/plugins.d/af_unix.conf

If write_logs = yes and the lines are still merged in audit.log, this points to a kernel audit buffer flush behavior, when multiple records belong to the same event and are emitted rapidly, some auditd versions write them without a separating newline.

Another question: Is this happening for all the logs originating from audit.log or just occasionally? I also noticed this was not happening when the logs were parsed via syslog until we piped it towards audit log.

Please let me know what you find.