Re: truss -f timeout 2 sleep 10 causes breakage
On Wed, Mar 27, 2024 at 01:00:07PM +0100, Mateusz Guzik wrote: > 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. > > 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. > > It does react to -9 though. Not the workqueue, which is the problem.
Re: truss -f timeout 2 sleep 10 causes breakage
Mateusz Guzik writes: > Top of main, but I reproduced it on stable/14-e64d827d3 as well. Confirmed on 14.0-RELEASE-p5. > 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. > and the entire thing refuses to exit, truss has to be killed off > with SIGKILL. This, however, is not expected. > 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 - d...@freebsd.org
truss -f timeout 2 sleep 10 causes breakage
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
