Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Jan 2021 21:32:15 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Vasily Postnicov <shamaz.mazum@gmail.com>
Cc:        Mark Johnston <markj@freebsd.org>, freebsd-net@freebsd.org
Subject:   Re: DNS using Name Service Switch module and Casper
Message-ID:  <X/izP6G03eOSN/Ph@kib.kiev.ua>
In-Reply-To: <CADnZ6Bm96bjJN5gcpCWiNKbNou3XvxZmCD2-YbX34%2B00L=UdPw@mail.gmail.com>
References:  <CADnZ6Bke=9%2B_pMc6rkbheNUWS-H6_X14%2Bf%2BWz5cfUCD=BTwk=g@mail.gmail.com> <X/R7Ahz8sz5v%2BoFa@raichu> <CADnZ6BmUJxVZx155j8opJKNsHJBE5mWz9D=MBE0Y_xu-kgOBfQ@mail.gmail.com> <X/h%2BJRmXmrOfmXBM@raichu> <CADnZ6Bm96bjJN5gcpCWiNKbNou3XvxZmCD2-YbX34%2B00L=UdPw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X/izP6G03eOSN/Ph>