On Wed, Oct 29, 2025 at 7:18 AM radmal <[email protected]> wrote: > Hi, > > It worked fine for two months, but now we’ve had the same issue again. > > I tried running strace, but ran into another problem. > I left strace -p guacPID running overnight in a screen session, and in > the morning I found the issue shown in the screenshot, users were unable > to log into their connections. > ``` > > As soon as I stopped the strace process in the screen session, everything > started working again immediately. > > Do you have any advice on how I could safely run strace again in case the > same or a similar issue happens in the future? >
Actually, when I asked for the stack trace, I meant use "gdb" to get the stack trace (bt or backtrace) in gdb from the coredump. strace gives you all of that information, because it's tracing all of the calls, but the most useful thing at this point is just to know where it's crashing and the last few things on the stack when it does crash, which is what gdb will give you. The stack trace was actually partially in the previous output you posted in your original e-mail, but it was truncated: Aug 1 07:53:10 srv-guacamole1 systemd-coredump[71142]: Process 71045 (guacd) of user 986 dumped core.#012#012Stack trace of thread 71107:#012#0 0x00007ffff728bedc __pthread_kill_implementation (libc.so.6 + 0x8bedc)#012#1 0x00007ffff723eb46 raise (libc.s> 0x00007ffff7fa2e63 guac_flag_wait_and_lock If you can get the full stack trace, that's what I was looking for. I suspect that running strace on the process may be resource-constraining your system and causing the hang for the users, so I would definitely not recommend doing that while you have users on the system, except in very limited debugging cases. -Nick
