Re: Process stuck in unkillable state if operating with inotify

From: Oleg Nauman <oleg.nauman_at_gmail.com>
Date: Thu, 10 Jul 2025 08:06:00 UTC 
On Thu, Jul 10, 2025 at 10:20 AM Konstantin Belousov
<kostikbel@gmail.com> wrote:
>
> 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.

 Yes it is and fixed this issue

Thank you

>