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