DNS using Name Service Switch module and Casper
Konstantin Belousov
kostikbel at gmail.com
Fri Jan 8 19:32:23 UTC 2021
On Fri, Jan 08, 2021 at 08:17:25PM +0300, Vasily Postnicov wrote:
> I have noticed that after I kill stuck ping, the process spawned with
> cap_init() remains. I cannot even kill it with SIGKILL. This is the
> output of procstat on such a process.
>
>
> vasily 969 0.0 0.1 26428 6532 v0 I 22:43 0:00.00 ping
> vonbraun.local
> vasily 983 0.0 0.1 26428 6532 v0 I 22:43 0:00.00 ping
> resurrected.local
> vasily 1024 0.0 0.1 26428 6532 v0 I 22:49 0:00.00 ping
> resurrected.local
> vasily 1028 0.0 0.1 26428 6532 v0 I 22:49 0:00.00 ping
> resurrected.local
> root 1089 0.0 0.0 12976 2512 v1 S+ 22:58 0:00.01 grep ping
> PID TID COMM TDNAME KSTACK
> 1028 100579 ping - mi_switch+0x155
> sleepq_switch+0x109 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9
> _sleep+0x2aa umtxq_sleep+0x19e do_lock_umutex+0x744
> __umtx_op_wait_umutex+0x49 sys__umtx_op+0x7a amd64_syscall+0x12e
> fast_syscall_common+0xf8
This is strange, I sprinkled enough checks for stops and kills into
kern_umtx:do_lock_*(), I believe. Also, if there is kill pending,
sleepq_catch_signal() should not remove the thread from runq. I would
expect that there is such bug if this thread went into loop with 100%
CPU usage, but by your report it sleeps.
Could it be that you need to kill ping from root? If killing from root
does not help:
What is the kernel version?
Can you provide minimal standalone binary that reproduces this situation?
I do not even need sources, binary alone which does not use any libraries
not from base, is enough.
More information about the freebsd-net
mailing list