Re: Does audit work on stable/12? Audit-related panic on latest stable/12
- In reply to: Alan Somers : "Re: Does audit work on stable/12? Audit-related panic on latest stable/12"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 19 Oct 2021 08:35:51 UTC
On 19.10.2021 7:36, Alan Somers wrote: >> I've upgraded one of my servers from 11.4 to latest stable/12. This server is unique in me fleet because it has audit (and auditd) enabled. >> >> First of all, right after (source-based, buildworld & Ko) upgrade dmesg becomes flooded with: >> >> BSM conversion requested for unknown event 43224 >> BSM conversion requested for unknown event 43225 >> BSM conversion requested for unknown event 43234 >> BSM conversion requested for unknown event 43238 >> >> And after several minutes of work I've got panic: >> >> Sleeping thread (tid 101199, pid 51147) owns a non-sleepable lock >> BSM conversion requested for unknown event 43224 >> KDB: stack backtrace of thread 101199: >> #0 0xffffffff804d0f34 at mi_switch+0xd4 >> BSM conversion requested for unknown event 43224 >> BSM conversion requested for unknown event 43224 >> #1 0xffffffff8051ca2c at sleepq_wait+0x2c >> #2 0xffffffff80467d62 at _cv_wait+0xf2 >> #3 0xffffffff80719573 at audit_commit+0x243 >> #4 0xffffffff80719866 at audit_syscall_exit+0x26 >> #5 0xffffffff804d7f8a at kern_thr_exit+0x14a >> #6 0xffffffff804d7e37 at sys_thr_exit+0x67 >> #7 0xffffffff807a1557 at amd64_syscall+0x387 >> #8 0xffffffff8077a7ae at fast_syscall_common+0xf8 >> panic: sleeping thread >> cpuid = 6 >> time = 1634604615 >> KDB: stack backtrace: >> #0 0xffffffff8050e925 at kdb_backtrace+0x65 >> #1 0xffffffff804c5bcb at vpanic+0x17b >> #2 0xffffffff804c5a43 at panic+0x43 >> #3 0xffffffff80523702 at propagate_priority+0x282 >> #4 0xffffffff805242cc at turnstile_wait+0x30c >> #5 0xffffffff804abd29 at __mtx_lock_sleep+0x199 >> #6 0xffffffff804d7ec2 at kern_thr_exit+0x82 >> #7 0xffffffff804d7e37 at sys_thr_exit+0x67 >> #8 0xffffffff807a1557 at amd64_syscall+0x387 >> #9 0xffffffff8077a7ae at fast_syscall_common+0xf8 >> >> >> Now, I've turned off auditd and server looks Ok (at least, it is stable for 30 minutes). But I need audit on this server. Is it known problem? Is it configuration problem? > > audit has at least some coverage in CI, but apparently not enough. > Would you share your /etc/security configuration? Event 43224 is /etc/security was merged from my old (stable/11 era) config by `mergemaster`. Here result is: audit_control: # # $FreeBSD$ # host:<ip redacted> dir:/var/audit minfree:5 dist:off flags:lo,aa,fc,-fd,fw,pc,nt,ex naflags:lo,aa,fc,-fd,fw,pc,nt,ex policy:cnt,argv filesz:200M expire-after:356d OR 50G audit_user: # # $FreeBSD$ # root:lo:no daemon::+fw,+fc,+fd operator::+fw,+fc,+fd bin::+fw,+fc,+fd tty::+fw,+fc,+fd kmem::+fw,+fc,+fd games::+fw,+fc,+fd news::+fw,+fc,+fd man::+fw,+fc,+fd sshd::+fw,+fc,+fd smmsp::+fw,+fc,+fd mailnull::+fw,+fc,+fd bind::+fw,+fc,+fd proxy::+fw,+fc,+fd _pflogd::+fw,+fc,+fd _dhcp::+fw,+fc,+fd uucp::+fw,+fc,+fd pop::+fw,+fc,+fd www::+fw,+fc,+fd hast::+fw,+fc,+fd nobody::+fw,+fc,+fd mysql::+fw,+fc,+fd postfix::+fw,+fc,+fd dovecot::+fw,+fc,+fd dovenull::+fw,+fc,+fd All other audit_* files are identical with source ones. > thr_new, which certainly should be known everywhere, so I'm wondering > if you have a bad build somehow. Are you using GENERIC or do you have > a custom kernel config? It is custom (trimmed) kernel config. Nothing special, only most of devices (which is not actual on this hardware) are stripped. -- // Lev Serebryakov