Hot answers tagged screen
If you're using Bash, you can run "disown -h job" disown disown [-ar] [-h] [jobspec ...] Without options, each jobspec is removed from the table of active jobs. If the -h' option is given, the job is not removed from the table, but is marked so that SIGHUP is not sent to the job if the shell receives a SIGHUP. If jobspec is not present, ...
Try running script /dev/null as the user you su to before launching screen - its a ghetto little hack, but it should make screen happy.
This isn't an answer, but a workaround. Use screen. When you first log in, run screen. You get another shell, run commands in that. If you're disconnected, the screen process keeps the terminal alive so that your shell and the processes it is running don't fall over. When you reconnect, run 'screen -r' to resume. There's a bunch more to configuring and ...
You can press ctrl-z to interrupt the process and then run bg to make it run in the background. You can show a numbered list all processes backgrounded in this manner with jobs. Then you can run disown %1 (replace 1 with the process number output by jobs) to detach the process from the terminal. In spite of the name, the process will still be owned by you ...
Have a look at reptyr, which does exactly that. The github page has all the information. reptyr - A tool for "re-ptying" programs. reptyr is a utility for taking an existing running program and attaching it to a new terminal. Started a long-running process over ssh, but have to leave and don't want to interrupt it? Just start a screen, ...
Use reptyr From the README: reptyr - A tool for "re-ptying" programs. ----------------------------------------- reptyr is a utility for taking an existing running program and attaching it to a new terminal. Started a long-running process over ssh, but have to leave and don't want to interrupt it? Just start a screen, use reptyr to grab it, and then kill ...
You could try Ctrl-a : source ~/.screenrc.
Try to set ClientAliveInterval (e.g. 60) and TCPKeepAlive (yes or no) to appropriate values on the serverside sshd.conf . This should keep your session alive even if the connection gets lost for minutes.
Try using the -t option to ssh ssh -t firstname.lastname@example.org screen "tail -f /var/log/messages" From man ssh -t Force pseudo-tty allocation. This can be used to execute arbi- trary screen-based programs on a remote machine, which can be very useful, e.g., when implementing menu services. Multiple -t options force tty allocation, ...
As mentioned above, GNU Screen is the way to go. It will allow you to have a 'screen session' on the remote box that you can run multiple commands in, via multiple 'screen windows'. This will simply detach if your parent SSH connection dies, keeping all the subprocesses running within it alive and well. 'man screen' is your friend as usual, and the OS ...
This answer doesn't solve the problem, but it's left here because 30+ people found it useful, otherwise I would have deleted it long time ago. Write to /proc/*pid of the program*/fd/0. The fd subdirectory contains the descriptors of all the opened files and file descriptor 0 is the standard input (1 is stdout and 2 is stderr). Example Terminal 1: ...
You cannot do this, easily. I'd suggest making it a habit to start screen as the first thing you do after opening a console. However, for your actual problem, there's another thing you could try: after having launched your job from the terminal, background it by typing ctrl-z and then bg. After that, detach the job from it's parent shell; in bash you'd do ...
As you're using Linux, what about using retty inside the newly launched screen process? $ screen -S my_process $ retty $(pgrep my_process) /redraw HTH cheers,
I love using it for connecting to serial consoles, i.e. screen /dev/ttyS0 19200 This command simply opens up a connection to serial port 0 (ttyS0) with a baud speed of 19200
Well, technically you're not redirecting anything here. Calling script /dev/null just makes script save the whole typescript into /dev/null which in practice means discarding the contents. See man script for detailed info and util-linux-ng package for implementation (misc-utils/script.c). This has nothing to do with screen actually. Why this works is ...
You might also check out the Screen FAQ which allows a sort of hybrid behavior: Summary: add the line to your .screenrc file: termcapinfo xterm ti@:te@ Reference ( Putty FAQ ) PuTTY's terminal emulator has always had the policy that when the ‘alternate screen’ is in use, nothing is added to the scrollback. This is because the usual sorts ...
You can look at the $STY variable. If it is not "" then you are in a screen session. I am in screen $ echo $STY 29624.pts-1.iain-10-04 $ I am not in screen $ echo $STY $
You can use: ssh root@host screen -m -d "tail -f /var/log/messages" That starts a detached screen with a command running on it. -m causes screen to ignore the $STY environment variable. With "screen -m" creation of a new session is enforced, regardless whether screen is called from within another screen session or ...
For those wanting a less cryptic way of getting a nice screen set up, I can heartily recommend byobu (formerly called screen profiles). It gives you a nice default set of stuff at the bottom of the screen - the bottom line contains various handy status information, and the second from bottom line contains a list of your screen windows. All this can be ...
To steal a process from one tty to your current tty, you may want to try this hack: http://www.ucc.asn.au/~dagobah/things/grab.c It needs some reformatting in order to compile to current Linux/glibc versions, but still works.
Tell screen to be a bit more persistent about trying: -D -R Attach here and now. In detail this means: If a session is run- ning, then reattach. If necessary detach and logout remotely first. If it was not running create it and notify the user. This is the author's favorite. So combine the two and you should have your solution ...
I tried the option mentioned here - Ctrl-a : source ~/.screenrc and it didn't work for me. This is what worked for me - Ctrl-a : source $HOME/.screenrc
You can look at the $TERM variable. echo $TERM If it's a screen session, the term variable should return "screen". root@deore:/volumes# echo $TERM screen Ctrl-a -d (to exit screen) root@deore:/volumes# echo $TERM xterm Also check: http://stackoverflow.com/questions/3472287/how-do-you-tell-if-the-current-terminal-session-is-in-gnu-screen
I can't believe no one has mentioned MOSH; Mosh is an SSH wrapper, it keeps your session alive after days of disconnection, changing IP, high latency and so on. It is explain on the home page better than I can explain it so I have copied the description below. My experiences and advice are that I use it on my Android mobile, it's a life saver when ...
When a process starts, STDIN, STDOUT and STDERR are connected to something. Generally you can't change that once the command is started. In the case you're describing, that's probably a tty associated with the ssh session. nohup pretty much just does ... command < /dev/null > nohup.out 2>&1 That is, sets STDIN to /dev/null, STDOUT to a ...
This is what the 'screen' utility was invented for. Although I've used it mainly on Linux, there's absolutely no reason a port for your OS couldn't exist. It's part of the gnu tool set, and I haven't found a port, but one probably exists (or could).
I've seen this when I drop a connection to an active screen then reconnect. Bug #27462 ("Reconnect stalls when original session is lost") describes the problem as I see it. What appears to happen is that screen is trying to notify the tty that holds it that it is about to leave, but since the tty is hung due to a dropped connection it has to wait for the ...
You can modify .screenrc to allow mouse-based scrollback: http://slaptijack.com/system-administration/mac-os-x-terminal-and-gnu-screen-scrollback/
Screen based solution Start the server like this: # screen -d -m -S ServerFault tr a-z A-Z # replace with your server screen will start in detached mode, so if you want to see what's going on, run: # screen -r ServerFault Control the server like this: # screen -S ServerFault -p 0 -X stuff "stop^M" # screen -S ServerFault -p 0 -X stuff "start^M" # ...
Thanks to this post, what I did was add one line to ~/.screenrc: # ~/.screenrc defshell -bash # dash makes it a login shell Then things in your ~/.bashrc, /etc/bashrc, etc. should get run.
Only top voted, non community-wiki answers of a minimum length are eligible