Re: Process stuck in unkillable state if operating with inotify

Reply: Oleg Nauman : "Re: Process stuck in unkillable state if operating with inotify"
In reply to: Oleg Nauman : "Process stuck in unkillable state if operating with inotify"
Go to: [ bottom of page ] [ top of archives ] [ this month ]

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Thu, 10 Jul 2025 07:19:14 UTC

On Thu, Jul 10, 2025 at 10:06:52AM +0300, Oleg Nauman wrote:
> I noticed that some processes consume 100% of CPU and unkillable even
> with kill -9
> System info: CURRENT 17f0f75308f2 ( Jul 8 ) amd64
> 
> The only meaningful info I was able to collect it is output of
> procstat -kk, so two examples of call stack for such type of
> processes:
> 
>   PID    TID COMM                TDNAME              KSTACK
>  3192 100876 polkitd             -
> _vn_lock_fallback+0x9e _vn_lock+0x8a vfs_lookup+0x122 namei+0x26d
> vn_inotify_add_watch+0x1b9 VOP_INOTIFY_ADD_WATCH+0x3a
> kern_inotify_add_watch+0x2be amd64_syscall+0x118
> fast_syscall_common+0xf8
>  3192 100889 polkitd             gmain               mi_switch+0xbc
> sleepq_catch_signals+0x27d sleepq_wait_sig+0x9 _cv_wait_sig+0xf5
> seltdwait+0x9a kern_poll_kfds+0x517 kern_poll+0x107 sys_ppoll+0x70
> amd64_syscall+0x118 fast_syscall_common+0xf8
> 
> and
> 
>   PID    TID COMM                TDNAME              KSTACK
> 58129 100829 packagekitd         -                   ffs_lock+0x7d
> _vn_lock_fallback+0x9e _vn_lock+0x8a vfs_lookup+0x122 namei+0x26d
> vn_inotify_add_watch+0x1b9 VOP_INOTIFY_ADD_WATCH+0x3a
> kern_inotify_add_watch+0x2be amd64_syscall+0x118
> fast_syscall_common+0xf8
> 58129 103627 packagekitd         pool-spawner        mi_switch+0xbc
> sleepq_catch_signals+0x27d sleepq_wait_sig+0x9 _sleep+0x197
> umtxq_sleep+0x2c1 do_wait+0x258 __umtx_op_wait_uint_private+0x54
> sys__umtx_op+0x7e amd64_syscall+0x118 fast_syscall_common+0xf8
> 58129 103628 packagekitd         gmain               mi_switch+0xbc
> sleepq_catch_signals+0x27d sleepq_wait_sig+0x9 _cv_wait_sig+0xf5
> seltdwait+0x9a kern_poll_kfds+0x517 kern_poll+0x107 sys_ppoll+0x70
> amd64_syscall+0x118 fast_syscall_common+0xf8
> 58129 103629 packagekitd         gdbus               mi_switch+0xbc
> sleepq_catch_signals+0x27d sleepq_wait_sig+0x9 _cv_wait_sig+0xf5
> seltdwait+0x9a kern_poll_kfds+0x517 kern_poll+0x107 sys_ppoll+0x70
> amd64_syscall+0x118 fast_syscall_common+0xf8

Try D51233.  This is a guess, not diagnosis.