When i re-attach to an existing/running window, the screen doesn't seem to be responding.
I can key in the input but no output displayed on the screen. When i do screen -ls, the screen and the socket is still there.
Anyone has any idea what could have probably happened prior to this? I could only restore the functionality by rebooting the server. Not sure if something has been broken between the screen and shell due to bad characters.
I've seen this happen -- typically when I foolishly suspended output to my terminal (like when I fat finger and hit CTRL-S or some other nonsense). We leave quite a few processes running in screen, so it's always a panic moment when we get a hung screen session.
The solution is to identify the sshd session associated with screen, and kill it. This will free the screen and allow you to re-attach from another ssh session. (note: be careful to NOT kill the main sshd or you may not be able to login remotely).
I find pstree -ac invaluable in these situations.
If the command that you run for the screen will terminate soon, the screen will show as blank and not show the output.
But if you run command like top python3 -m http.server nano * that will not terminate soon, the screen will show.
EDIT
To solve this problem, you can run exec echo "hello world" after create screen.
Related
The terminal begins to behave a little bit strangely after an SSH session inside has been terminated (due to sleeping the computer or killing it via <Enter>+~+.).
It causes a beep to be emitted whenever focus enters and leaves the particular terminal. Also when in my zsh shell, a blank new line appears to be fed into the terminal.
I've tested this in:
tmux in alacritty
raw alacritty
iTerm2
This is not a hugely annoying behavior, although the bell is definitely annoying for sure.
Today I was able to finally find a way to reproduce the behavior. Clearly this is somehow related to a terminal mode that SSH puts the terminal into and which it fails to clean up when it dies. But it is also related to the focus reporting.
I have tried stty sane but it does not work. Not even starting and quitting vim works. That usually is able to reset various other terminal state weirdnesses, such as being stuck in mouse mode where clicking the mouse on the terminal (and especially scrolling your mouse) produces lots of bells.
Inspired by the answer https://superuser.com/a/1017817/98199, I found that issuing the command echo '\x1b[?1004l' does effectively turn off the focus reporting, and restores normal behavior.
Since vim definitely is capable of recognizing focus events I do not know why starting and stopping vim does not do the trick for this. I suppose I will make this command into an alias and just run it when I need to.
The scroll bar in WSL is not usable while running a process. My attempts to scroll up are futile because the system automatically sets the scroll bar to the bottom of the window since there's a process running.
In my case, I invoked ./gradlew bootRun, which starts an application on 8080 and keeps printing logs. I tried to read the logs by scrolling up but any manual upward movement of scroll bar was being overridden.
Just wondering if some other Windows 10 setting is causing this or is it specific to bash or is it specific to gradle? How to fix it?
I believe this is neither related to WSL nor to the shell, but to the terminal. And even in case of WSL the terminal is still conhost, which is also used by the regular Windows cmd prompt.
That said, I don't believe there's a fix / setting for this right now, but you might have luck seeing this address in the new terminal app being created currently by Microsoft. In its current state, though, I also see it auto-scrolling to the bottom for ongoing output.
I tried using tmux with iTerm2 recently and it works perfectly for about one minute after I attach using the command via iTerm:
$ tmux -CC attach
However one minute after attaching, on the very next keystroke it detaches, as if it somehow timed out. This happens whether or not I do anything in the tmux window. The session is still there and I can reattach with no problems, but of course it disconnects again after a minute. I don't have this issue when using screen or when using tmux without the iTerm integration. Has anyone had a similar issue or know why iTerm may be detaching?
Figured it out! iTerm has the following feature:
"When idle, send ASCII code 0" (by default) Since I don't interact with the tmux control window, it sends the null ASCII code after one minute, which appears to cleanly detach the session. It doesn't matter what I do in the tmux windows, whether they are idle or not.
So glad to have worked this out. Not sure why I had this enabled, as I don't think I need it. It explains some other odd issues I have noticed once or twice (randomly pasting in vim, etc)
Goodbye, screen!
I'm trying to debug why tmux processes still think they're attached when I close the terminal they live inside of, and I think I've discovered part of the problem; when I close a terminal window (CMD-W or clicking the little red button in the top left) it doesn't send SIGHUP! In fact, it only sends SIGEXIT. I discovered this using the script from this SO question. One of the posters gave a very different result from his OSX machine, however my terminal does not seem to want to play nicely.
Does anyone know how to make the terminal in OSX (I'm running 10.7.2) send the proper signals when exiting? Thanks!
I'd like to be able to launch a process from a GUI application (right now I'm thinking specifically of letting an eclipse user -- possibly via a plugin -- click a button to launch a build using my organization's build system).
I don't want this process to stop when I stop the parent application, and I want to be able to "switch into it" later, as though I launched it from a command line.
I've seen GNU screen described as good for most of what I'm asking for, but I'm not sure about the "launch the process from another application" part.
Can this be done if the GUI application was itself launched from within screen? Can this be done if it wasn't? I'd be very interested in seeing how!
Update:
Prepending "screen" to a command line looks like a good way to start a process in screen from a shell, but I'm trying to find a way to do this without being taken straight into that session. I want to "send" the command to a screen session, where it will be started in a new window in that session.
simply prepend the 'screen' command to your normal commandline.
E.g. if you normally execute "./make_build.sh opt1 opt" then your screenified commandline would be "screen ./make_build.sh opt1 opt2"
Its that easy! :-)
You can send screen messages to a running screen session with the -X flag.
See How to start a new process in a new window in an existing GNU screen session, from outside the session or the screen man pages.
If you can suspend the process (via Cont-Z) you can then run
screen -dr -X screen $(fg)
It will attach that process to a new window in the screen. Its not ideal, but it will work.