Discussion:
truss -f timeout 2 sleep 10 causes breakage
(too old to reply)
Mateusz Guzik
2024-03-27 12:00:07 UTC
Permalink
Top of main, but I reproduced it on stable/14-e64d827d3 as well.

Mere "timeout 2 sleep 10" correctly times out.

Running "truss -f timeout 2 sleep 10" prevents timeout from killing
sleep and the entire thing refuses to exit, truss has to be killed off
with SIGKILL.

Here is the best part: after doing the above, going back to mere
"timeout 2 sleep 10" (without truss!) no longer works -- timeout gets
stuck in the kernel: mi_switch sleepq_catch_signals sleepq_wait_sig
_sx_xlock_hard stop_all_proc_block kern_procctl sys_procctl
amd64_syscall fast_syscall_common

It does react to -9 though.
--
Mateusz Guzik <mjguzik gmail.com>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Dag-Erling Smørgrav
2024-03-27 12:16:13 UTC
Permalink
Post by Mateusz Guzik
Top of main, but I reproduced it on stable/14-e64d827d3 as well.
Confirmed on 14.0-RELEASE-p5.
Post by Mateusz Guzik
Mere "timeout 2 sleep 10" correctly times out.
Running "truss -f timeout 2 sleep 10" prevents timeout from killing
sleep
This is sort of expected as truss(1) uses ptrace(2) which breaks the
parent-child relationship, so you should never use `truss -f` with a
command that expects to control its children.
Post by Mateusz Guzik
and the entire thing refuses to exit, truss has to be killed off
with SIGKILL.
This, however, is not expected.
Post by Mateusz Guzik
Here is the best part: after doing the above, going back to mere
"timeout 2 sleep 10" (without truss!) no longer works
Neither is this.

DES
--
Dag-Erling Smørgrav - ***@FreeBSD.org


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Konstantin Belousov
2024-03-27 12:34:19 UTC
Permalink
Post by Mateusz Guzik
Top of main, but I reproduced it on stable/14-e64d827d3 as well.
Mere "timeout 2 sleep 10" correctly times out.
Running "truss -f timeout 2 sleep 10" prevents timeout from killing
sleep and the entire thing refuses to exit, truss has to be killed off
with SIGKILL.
The issue is because debugger can stop the debuggee, which makes the
single threading never succeed. Supposed fix is in
https://reviews.freebsd.org/D44523
the cost is that in principle, the debuggee now can try to break out of
the reaper kill hammer, with the help of debugger. But this setup is
arguably too convoluted: you either control the process with reaper, or
with debugger.
Post by Mateusz Guzik
Here is the best part: after doing the above, going back to mere
"timeout 2 sleep 10" (without truss!) no longer works -- timeout gets
stuck in the kernel: mi_switch sleepq_catch_signals sleepq_wait_sig
_sx_xlock_hard stop_all_proc_block kern_procctl sys_procctl
amd64_syscall fast_syscall_common
This is because the threaded workqueue thread is stuck waiting for
single-threading of the victim.
Post by Mateusz Guzik
It does react to -9 though.
Not the workqueue, which is the problem.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...