From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: why I have lost messages on boot even with very big backlog while I hunting only 2 syscalls? Date: Thu, 28 Sep 2017 10:02:33 -0400 Message-ID: <1801496.66AHGvC9ka@x2> References: <1381531506544889@web29j.yandex.ru> <3751114.k3uyVqUoiX@x2> <35811506588698@web59g.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <35811506588698@web59g.yandex.ru> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Lev Olshvang Cc: "linux-audit@redhat.com" List-Id: linux-audit@redhat.com Hello, On Thursday, September 28, 2017 4:51:38 AM EDT Lev Olshvang wrote: > 28.09.2017, 00:32, "Steve Grubb" : > > 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 > > Hi Steve > > Thank you for your answer. > I added backlog parameter as you advised, but it did not solve the problem > > > cat /proc/cmdline > BOOT_IMAGE=/vmlinuz-4.8.0-59-generic root=/dev/mapper/kubuntu--vg-root ro > net.ifnames=0 biosdevname=0 audit=1 audit_backlog_limit=8192 debug splash > auditctl -s > enabled 1 > failure 1 > pid 672 > rate_limit 0 > backlog_limit 16384 > lost 16 > backlog 10 > backlog_wait_time 30 > loginuid_immutable 0 unlocked > > Perhaps something else in configuration ? You have a backlog of 10. That should normally be 0 unless the system is very busy. What do you have for the flush and freq settings in auditd.conf? -Steve