Re: why I have lost messages on boot even with very big backlog while I hunting only 2 syscalls?

On Wednesday, September 27, 2017 4:41:29 PM EDT Lev Olshvang wrote: >  Hello list ! > >  A very technical question >  I have Ubuntu 16.10 Virtual Box , auditd 2.7.8 >  I have audit=1 parameter in grub.cfg >  I see that /proc/cmdline indeed sees it > >  I see that auditd is started with PID 564 > >  root 312 2 0 23:12 ? 00:00:00 [kauditd] >  root 564 1 0 23:12 ? 00:00:00 /sbin/auditd > >  And I have 15 lost messages ??? >  auditctl -s >  enabled 1 >  failure 1 >  pid 564 >  rate_limit 0 >  backlog_limit 16384 >  lost 15 >  backlog 0 >  backlog_wait_time 30 >  loginuid_immutable 0 unlocked > >  auditctl -l >  -a always,exit -F arch=b64 -S execve,execveat -F key=exec > >  Do I understand correctly that auiditd is indeed started by systemd before >  other services, except 2 that is listed in auditd.service dependencuies - >  local-fs and some temp setup of systemd ? Yes, it is started before most services. However. systemd-journal for some reason feels obligated to enable auditing. And sometimes people put audit=1 on the kernel command line. Either way, auditing is on way before auditd starts. The audit logs have a 64 entry buffer by default. So, as the system boots events pile up and eventually overflows the 64 entry limit. The fix is to add another boot command option audit_backlog_limit=8192 or some other suitable number. The test to check for this is to boot your system, login and run auditctl -s. If you have just booted and lost events during boot, this should fix it. -Steve