Solaris Hang When Kernel Threads Are Blocked In audit_sync_block (Doc ID 1010717.1)

Last updated on JANUARY 15, 2024

Applies to:

Symptoms

You may encounter a system hang and then find several kernel threads are sleeping in audit_sync_block from a crashdump.

The following is an example of such a thread:

SolarisCAT(vmcore.0)> tlist findmodule c2audit
==== user thread: 0x30001c7ec60 pid: 2567 ====
cmd: /usr/sbin/cron
t_wchan: 0x104a3a50 sobj: condition var (from c2audit:audit_sync_block+0xfc)
t_stk: 0x2a10085daf0 sp: 0x2a10085cfd1 t_stkbase: 0x2a10085a000
t_pri: 52(TS) t_lwp: 0x30008be2b58 machpcb: 0x2a10085daf0
t_procp: 0x3001381d528 p_as: 0x30015643790 hat: 0x3000c7f9e68 cnum: 0x147e
size: 6619136 rss: 1433600
last cpuid: 0
idle: 282707 ticks (47 minutes 7.07 seconds)
start: Fri May 14 15:35:00 2004
age: 2841 seconds (47 minutes 21 seconds)
stime: 1158874174 (47 minutes 7.07 seconds earlier)
syscall: auditsys (0x23, 0xffbeea80)
tstate: TS_SLEEP - awaiting an event
tflg: none set
tpflg: TP_TWAIT - wait to be freed by lwp_wait
tsched: TS_LOAD - thread is in memory
TS_DONT_SWAP - thread/LWP should not be swapped
pflag: SLOAD - in core
SULOAD - u-block in core
NOCD - new creds from VSxID, do not coredump

pc: 0x10077b50 genunix:cv_wait+0x38: call unix:swtch

genunix:cv_wait+0x38 (0x104a3a50, 0x104a3a48, 0x104a3a50, 0x3000274a405, 0x0, 0x0)
c2audit:audit_sync_block+0xfc (0x104a3ac0, 0x104a39d4, 0x104a42d8, 0x104a3a10, 0xa07, 0x0)
c2audit:audit_finish+0x2fc (0x104a4000, 0x0, 0x0, 0x2a10085dae8, 0x80000, 0x108)
unix:audit_finish - frame recycled
genunix:post_syscall+0x70 (0x30001c7ec60, 0xba, 0x1, 0x23, 0x0, 0x0)
unix:_syscall_post32+0x0 (0xba, 0x23, 0xffbeea80, 0x28, 0x31314, 0x3)
-- switch to user thread's user stack --
...

Cause