I sent a window to a session that did not exist yet, hoping it would create a new session:
move-window -t <newsessionname>
Instead, the window just disappeared. No new session, nothing.
Does anyone know where the window might be? I am guessing the processes inside it are still running, though it's hard to tell because there's tons of instances of these programs on other windows. I don't really care about recovering the lost window, as much as about gracefully exiting from those processes if possible.
Related
I routinely run R remotely and have had great success with RStudio server to do so. However, Emacs/ESS is still preferable in many cases, particularly since I often work on multiple projects simultaneously. What is the start-of-the-art when running ESS/R in emacs when the expectation is that the connection will be broken? To be more concrete, I'd love to run a tmux session in Emacs so that I can connect to a long-running R session running in tmux (or screen). What is the status of ESS/Emacs to support such a scenario? This seems to be changing over time and I haven't found the "definitive" approach (perhaps there isn't one).
I do that all the time. At both home, and work.
Key components:
Start emacs in daemon mode: emacs --daemon &. Now emacs is long-running and persistent as it is disconnected from the front-end.
Connect using emacsclient -nw in text mode using tmux (or in my case, the byobu wrapper around tmux). As tmux persists, I can connect, disconnect, reconnect,... at will while having several tabs, split panes, ... from byobu/tmux.
When nearby -- on home desktop connecting to home server, or at work with several servers -- connect via emacsclient -c. Now I have the standard X11 goodness, plotting etc pp. That is my default 'working' mode.
But because each emacs session has an R session (or actually several, particularly at work) I can actually get to them as I can ssh into the tmux/byobu session too.
Another nice feature is tramp-mode allowing you to edit a remote file (possibly used by a remote R session) in a local Emacs buffer as tramp wraps around ssh and scp making the remote file appear local.
Last but not least mosh is very nice on the (Ubuntu) laptop as it automagically resumes sessions when I am back on the local network at home or work. In my case mosh from Debian/Ubuntu on server and client; may also work for you OS X folks.
In short, works like a dream, but may require the extra step of "disconnecting" emacs from the particularly tmux shell in which you launch. Daemon mode is key. Some of these sessions run on for weeks.
I started working like this maybe half a decade ago. Possibly longer. But using ESS to connect to remote Emacs session is much older -- I think the ESS manual already had entries for it when I first saw it in the late 1990s.
But I find this easier as it gives me "the whole emacs" including whatever other buffers and session I may need.
Edit: And just to be plain, I also use RStudio (Server) at home and work, but generally spend more time in Emacs for all the usual reasons.
More Edits: In follow-up to #kjhealy I added that I am also a fan of both tramp-mode (edit remote files locally in Emacs thanks to the magic that are ssh and scp) as well as mosh (sessions that magically resume when I get to work or back home).
When I start a process in background in a terminal and some how if terminal gets closed then we can not interact that process any more. I am not sure but I think process also get killed. Can any one please tell me how can I detach that process from my terminal. So even if I close terminal then I can interact with same process in new terminal ?
I am new to unix so your extra information will help me.
The command you're looking for is disown.
disown <processid>
This is as close as you can get to a nohup. It detaches the process from the current login and allows it to continue running. Thanks David Korn!
http://www2.research.att.com/~gsf/man/man1/disown.html
and I just found reptyr which lets you reparent a disowned process.
https://github.com/nelhage/reptyr
It's already in the packages for ubuntu.
BUT if you haven't started the process yet and you're planning on doing this in the future then the way to go is screen and tmux. I prefer screen.
You might also consider the screen command. It has the "restore my session" functionality. Admittedly I have never used it, and forgot about it.
Starting the process as a daemon, or with nohup might not do everything you want, in terms of re-capturing stdout/stdin.
There's a bunch of examples on the web. On google try, "unix screen command" and "unix screen tutorial":
http://www.thegeekstuff.com/2010/07/screen-command-examples/
GNU Screen: an introduction and beginner's tutorial
First google result for "UNIX demonizing a process":
See the daemon(3) manpage for a short overview. The main thing of daemonizing
is going into the background without quiting or holding anything up. A list of
things a process can do to achieve this:
fork()
setsid()
close/redirect stdin/stdout/stderr to /dev/null, and/or ignore SIGHUP/SIGPIPE.
chdir() to /.
If started as a root process, you also want to do the things you need to be root
for first, and then drop privileges. That is, change effective user to the "daemon"
user or "nobody" with setuid()/setgid(). If you can't drop all privileges and need
root access sometimes, use seteuid() to temporary drop it when not needed.
If you're forking a daemon then also setup child handlers and, if calling exec,
set the close on exec flags on all file descriptors your children won't need.
And here's a HOWTO on creating Unix daemons: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html
'Interact with' can mean a couple of things.
The reason why a program, started at the command-line, exits when the terminal ends, is because the shell, when it exits, sends that process a HUP signal (see documentation for kill(1) for some introduction; HUP, by the way, is short for 'hang up', and originally indicated that the user had hung up the modem/telephone). The default response to a HUP signal is that a process is terminated – that is, the invoked program exits.
The details are slightly more fiddly, but this is the general intuition.
The nohup command tells the shell to start the program, and to do so in a way that this HUP signal is ignored. That is, the program keeps going after the invoking terminal exits.
You can still interact with this program by sending it signals (see kill(1) again), but this is a very limited sort of interaction, and depends on your program being written to do sensible things when it receives those signals (signals USR1 and USR2 are useful things to trap, if you're into that sort of thing). Alternatively, you can interact via named pipes, or semaphores, or other bits of inter-process communication (IPC). That gets fiddly pretty quickly.
I suspect what you're after, though, is being able to reattach a terminal to the process. That's a rather more complicated process, and applications like screen do suitably complicated things behind the scenes to make that happen.
The nohup thing is a sort of quick-and-dirty daemonisation. The daemon(3) function does the daemonisation 'properly', doing various bits of tidy-up as described in YePhIcK's answer, to comprehensively break the link with the process/terminal that invoked it. You can interact with that daemonised process with the same IPC tools as above, but not straightforwardly with a terminal.
After reattaching a screen or tmux session over ssh, I commonly encounter two issues:
vim tab completion is broken. :e <Tab> produces :e ^I instead of suggesting files. Same for tags (:tj). Closing and re-opening vim fixes this, but at the cost of losing vim state.
R cannot produce graphics. I have X11 forwarding (ssh -X -Y) enabled. Closing and re-opening does not help.
I cannot deliberately reproduce the problem by closing my ssh window and re-attaching. Problem is usually observed after long periods without network connectivity between reattaching, and usually detaching is abrupt (loss of network connectivity).
Vim tab completion:
This is an issue with screen/tmux's terminal emulator. If tabs work in your shell (e.g. bash), that's likely to the shell's credit; it knew to map the control sequence for you while vim did not. Presumably, you could fix this in vim in a similar manner, but then you'd run into the issue in some other interactive program.
I can't speak to tmux, but for screen, you should look to update your ~/.screenrc. Mine, copied from the default that ships with Redhat (which I no longer use...), includes this:
#xterm understands both im/ic and doesn't have a status line.
#Note: Do not specify im and ic in the real termcap/info file as
#some programs (e.g. vi) will not work anymore.
termcap xterm hs#:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l
terminfo xterm hs#:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l
Heed that comment, it may indicate your issue.
Another reference to vi, which may or may not have come from Redhat's screenrc, is:
# Yet another hack:
# Prepend/append register [/] to the paste if ^a^] is pressed.
# This lets me have autoindent mode in vi.
register [ "\033:se noai\015a"
register ] "\033:se ai\015a"
bind ^] paste [.]
Hopefully one or both of these will help, or else I've pointed you in the right direction to research what you need to correct your screen/tmux terminal emulation. Perhaps the answers to screen, vimrc, and bashrc over at LinuxQuestions.org can help further.
X11 Forwarding:
When you first launch screen, the $DISPLAY is inherited. For example, I take advantage of this on my TV server; I launch screen locally (DISPLAY=localhost:0), then when I connect to it over SSH, anything I do regarding X pops up on the TV. Obviously, this is not at all your use case; I'm just trying to educate you on how it works so you can understand the solution.
If you are reconnecting to a screen/tmux session launched by an old SSH connection, you may luck out and have it connected to the same X display (SSH defaults to localhost:10.0 and then increments each time it finds a collision), but that doesn't sound like it's happening for you. (The "localhost" part is optional, as is the ".0" part. Those shouldn't matter for your purposes. DISPLAY=:10 is the same as DISPLAY=localhost:10.0)
Before you connect to your screen/tmux session, take a look at your $DISPLAY.
$ echo $DISPLAY
localhost:10.0
Then, log into screen/tmux and set the $DISPLAY to what you saw before.
$ screen -r
$ export DISPLAY=localhost:10.0
I don't think either screen or tmux are smart enough to go any farther than this (think of my TV server example; this isn't always desired, and asking screen/tmux to test the $DISPLAY and then act contingent on its availability is a bit much), so you have to do this manually.
(This may be annoying if you're like me and add screen -r >/dev/null 2>&1 in your ~/.bashrc. I don't run into this issue because I try to avoid X11 forwarding whenever possible due to its being slow as molasses and of course not surviving SSH disconnections.)
The second problem looks like a DISPLAY variable one. Try
echo $DISPLAY when you first login and again when you reattach the session.
if they differ (which is what i suspect), setenv or export it to the correct value.
As for the first problem try taking a look at your tmux.conf (or the default from your install)
cause they were remapping
<TAB> to funny actions in the development versions (like clear-history) so maybe
after the reattach, tmux owns the event and not vim.
In R, running under Ubuntu 11.10 with xfce4, if I accidentally type the key control-4, R quits immediately - no questions asked - which can be useful at times if I create a job that's just too big.
The trouble is that I occasionally accidentally hit ctrl-4 in the middle of work and lose it which is annoying.
How can I change this keycode to something else? or failing that just remove it altogether?
Thanks!
Ctrl-4 is sending the Unix Quit signal. Ctrl-\ will do it to.
To disable in a shell, do:
trap '' 3
then run R, try ctrl-\ or ctrl-4 - but anything else you wan to SIGQUIT will ignore it in that shell. Send a SIGKILL instead (kill -9).
I'm using mac/linux and I know that ctrl-z stops the currently running command in terminal, but I frequently see the process is still running when i check the system monitor. What is the right way to stop a command in terminal?
Typically I run into this issue when running python or ruby apps, i'm not sure if that has something to do with it, just thought I would add that.
Using control-z suspends the process (see the output from stty -a which lists the key stroke under susp). That leaves it running, but in suspended animation (so it is not using any CPU resources). It can be resumed later.
If you want to stop a program permanently, then any of interrupt (often control-c) or quit (often control-\) will stop the process, the latter producing a core dump (unless you've disabled them). You might also use a HUP or TERM signal (or, if really necessary, the KILL signal, but try the other signals first) sent to the process from another terminal; or you could use control-z to suspend the process and then send the death threat from the current terminal, and then bring the (about to die) process back into the foreground (fg).
Note that all key combinations are subject to change via the stty command or equivalents; the defaults may vary from system to system.
if you do ctrl-z and then type exit it will close background applications.
Ctrl+Q is another good way to kill the application.
Take a look at Job Control on UNIX systems
If you don't have control of your shell, simply hitting ctrl + C should stop the process. If that doesn't work, you can try ctrl + Z and using the jobs and kill -9 %<job #> to kill it. The '-9' is a type of signal. You can man kill to see a list of signals.