-
Notifications
You must be signed in to change notification settings - Fork 422
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LP hangs in tmux detection #806
Comments
This patch works for me:
timeout comes from coreutils. |
Hopefully you still have that tmux session around. Or have a way to reproduce this with your patch intact. What happens if you run I do not think your patch will be possible to merge. |
Hey @Rycieos, we debugged the issue and found out the The If we use old |
This is a possibilty from inside tmux. There is TMUX environment var:
2nd field is the pid of the tmux, so /proc/68128/exe list-sessions does the trick. but: When you are not inside a tmux sessions, i do not sea how to find the correct executable. |
I probably can break things for reproducing this bug :-)
tmux shows the correct output.
Unfortunately it is more complicated and i think it is not worth it to debug tmux detection or make this detection much more complicated. |
There are bash builtin possibilities: Maybe it is a good feature to limit the execution time of LP in general? |
I just talked to some embedded Linux people and they told me that Even busybox has a I hope you overthink your decision. |
I... find that hard to believe. The I still think this is a bug in tmux then. Why is the file handle not being closed? This would hang with any process attached to the stdout, like Could you capture the process tree once it hangs? If you are right, we should see a |
Yes, we need a solution that works in both situations.
What happens if you run
Unfortunately I (partially) disagree. I would prefer to see this fixed in tmux. The patch you suggested is not possible for me to merge, as I will explain below.
That linked solution will not work. The method it uses is creating a subshell that runs the command or function, and killing the subshell if it runs too long. But subshells are separate processes, and cannot set variables that will persist to the main shell. There might be some hack that would allow for returning a value on stdout from the subshell, but that would only work for single commands, not the prompt generation as a whole. And we try to avoid subshells as much as possible as they are very slow on some systems.
I agree. I think preventing prompt generation from being able to lock up your shell is very important. But as it stands, I do not know of any way to timeout in Bash that will work with functions and passing state around. Neither the
That is interesting, and useful information. However, Liquid Prompt supports more platforms than just Linux. We also support multiple forms of BSD, MacOS, and Windows. MacOS does not have
I am always open to rethinking my decisions. I have changed my mind on multiple features and bug fixes in Liquid Prompt in the past. And to be clear, I am open to adding a fix to Liquid Prompt for this issue (that I am pretty sure is a bug in tmux). The problem is only that your suggested fix is not portable. |
ACK - This only happens if we're using the updated
Yes, with the above scenario (old server, new client) also causes |
That's an strace of the
Here the relevant part of
Earlier in
|
This particular problem cannot be fixed in tmux, as it's during a Debian update, which updates tmux from some version to another. Both versions are already released. |
Sure, but a newer version of tmux could be released to prevent this lockup. I just don't know where else this could be fixed. I am open to ideas. Surely this is not an uncommon scenario to run into since tmux sessions can be so long running. |
Even after sleeping on it for a few nights, I only have one idea how to improve the situation: Disable tmux support in root shells in general or use timeout when on linux. |
Wait, what do root shells have to do with this? Does this bug only appear when tmux is run as root? Are you running the tmux session as root, then hanging in a normal user shell? Or the other way around; running tmux session as a normal user, then hanging in a root shell? |
No this always happens. |
When having different versions of tmux (old server, new client) the tmux detection can hang for an indefinite period.
This blocks all interaction with shell.
Shell: 5.2.15(1)-release
Operating system: Debian bullseye upgrade to bookworm (Kernel 5.10.0-26-amd64)
Liquid Prompt version: b1ea560 (master on 2023-11-13)
Steps to Reproduce
Expected Behavior
I expect that at some timeout using the shell is possible.
Current Behavior
It hangs forever. No Interaction with shell possible.
Possible Solution / Workaround
in Line
start grep with
timeout 1
The text was updated successfully, but these errors were encountered: