Date: Thu, 10 Jul 2025 11:06:00 +0300 From: Oleg Nauman <oleg.nauman@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Process stuck in unkillable state if operating with inotify Message-ID: <CAC5YPTv51nxwjOrs7d%2BjDvJ4Ned_Aqm8VMKuWZoFx%2BpZLG_e%2BQ@mail.gmail.com> In-Reply-To: <aG9pcpiCULNkKOHB@kib.kiev.ua> References: <CAC5YPTu%2B_KY7Jstz_x2aBsteXOKs5pUjnp1RASJAiQ7mM-D0Mw@mail.gmail.com> <aG9pcpiCULNkKOHB@kib.kiev.ua>
index | next in thread | previous in thread | raw e-mail
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 >home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAC5YPTv51nxwjOrs7d%2BjDvJ4Ned_Aqm8VMKuWZoFx%2BpZLG_e%2BQ>