I am already using Emacs server for some of the problems described in the documentation, For example, I have (server-start) in my .emacs init file, and I have set the EDITOR env. variable to emacsclient so that git and other programs don't open a new instance of Emacs when they need me to type text or log message. This is working great so far.
I am now wondering if I can use Emacs server for something else: I often launch Emacs remotely through an ssh -X session. Sometimes I need to close the ssh session (e.g. I need to reboot my local computer) and re-connect. It would be great if instead of fully closing Emacs for this, I could detach from Emacs, and reattach later.
Is this possible with Emacs server? I believe from things I have read online that the answer is yes, but:
My question:
How can I safely detach from an Emacs server and reattach later?
If you directly start Emacs from within the SSH session, you cannot gracefully detach, because the Emacs process becomes part of the process group created by the remote shell, and if the shell exists it will terminate all processes in its process groups.
However, you can start Emacs in Daemon mode first, with emacs --daemon. Emacs will load the configuration, start an edit server (even without an explicit (server-start) in your configuration), and detach from the terminal. This Emacs daemon will stay alive across different SSH session.
Subsequently, only use emacsclient to connect to the running daemon.
emacs --daemon or (server-start) in .emacs.
Next use emacsclient file, emacsclient -n file or emacsclient -c for just an attaching.
To leave attach as usual C-x C-c.
Related
On a Mac OS, I am able to run Emacs as a daemon and then the emacs binary. But, according to "Mastering Emacs" of Mickey Peterson (see the quote below), I should not be able to do that. Where do I misunderstand the book?
emacs --daemon will run Emacs as a daemon. It will call server-start,
as above, but will return control to your terminal immediately and run in the background, waiting for client
requests.
If you go the server route, you cannot use the default emacs binary
any more.
On a Mac Os, I launch Emacs with "/Applications/Emacs.app/Contents/MacOS/Emacs" from the command line.
The quote is misleading. After you have started a server you can happily run either emacs or emacsclient as you wish. The latter will connect to your server; the former will (as usual) start a new separate instance of Emacs.
I have been using emacs with tramp for a few weeks now to ssh into a server and edit some files. I do this by C-x C-f /ssh:username#server.com. Suddenly this has stopped working. I am getting "Waiting for prompts from remote shell problem" message.
However, If I don't provide a username (C-x C-f /ssh:server.com) then the connection seems to get established.
I am running emacs 24 using cygwin. How can I get this connection to work again?
There is one relatively common reason (at least on Windows/Cygwin platform): the ssh process started by tramp gets somehow stuck and unresponsive.
On my current desktop this happens once every month or so.
Just kill any ssh processes, either from your favourite cygwin terminal (with kill -9) or from your Windows task manager. This gets everything working again.
I have never encountered this problem on Linux, only on Windows/Cygwin.
I configured and started an emacs server in TCP mode:
Added (setq server-host "10.16.184.33") and (setq server-use-tcp t) to .emacs
ran emacs --daemon
On the same host, running emacsclient -t brings up an emacs frame in the current terminal, and running emacsclient -c brings up a new graphical client frame, as expected.
On a different host, running emacsclient -t -f ~/.emacs.d/server/server appears to successfully connect to the remote emacs server, but no frame is created in the terminal:
$ emacsclient -t -f ~/.emacs.d/server/server
emacsclient: connected to remote socket at 10.16.184.33
At this point, emacsclient is running in the foreground, and a Ctrl-c stops it with a SIGTERM.
the value of the server-client variable shows that remote emacs client is connected:
server-clients's value is
(#<process server <10.16.184.33:52710>> #<process server <10.16.177.8:59460>>)
Things that I've checked:
versions of Emacs and emacsclient: all 24.3
when swapping which machines are the server and the remote client, the same problem occurs, except...
emacsclient prints an extra error message
emacsclient: connected to remote socket at 10.16.177.8
*ERROR*: Could not open file: /dev/pts/26
Any ideas of what else to check or configure?
There is nothing you could “check or configure”. You simply cannot use emacsclient remotely, because both processes share the frame, which does not work remotely for obvious reasons.
If a client connects to an Emacs server, it does not actually create the frame itself. Rather, it merely tells the server what kind of frame to create, i.e. whether a GUI frame or a terminal frame. The server then creates the frame based on the client's request and parameters.
Specifically, in case of a TTY client (i.e. emacsclient -t) the server attempts to create a frame on the client's TTY. Obviously this won't work if the server runs on a different system. TTYs are local and not remotely accessible.
FYI, the “TCP mode” of the Emacs server was never intended for remote access. It is simply a workaround for systems which do not support local Unix sockets, that is, Windows.
You don't even want to try and make it work, because it's horribly insecure. Being intended as local protocol, Emacs server does neither support traffic encryption nor authentication. By running a remotely accessible Emacs server, you allow any other system to execute arbitrary Emacs Lisp on your machine.
The right way to use Emacs remotely is SSH. Setup an SSH server on the remote system, then connect to the system via SSH and start emacsclient -t in the remote shell.
It's well known that emacs can be used as a terminal emulator (while itself is running in a terminal emulator), thus making it a valid alternative to more traditional terminal-in-a-terminal approaches, such as tmux or screen. However, there's one thing that could be done easily with the latter and I've found no alternative in emacs' term for this one so far.
Both tmux and screen can detach from a terminal and all tasks ran in their windows continue to run in background. It's done using C-b, d in tmux and C-a, d in screen by default. Later, I can return (reattach) to the terminal I've detached from by running something like tmux attach or screen -r. Also, sessions run in both of these terminal multiplexers are persistent - i.e. if I'm connected to some remote terminal and connection fails, I can reconnect and reattach to the terminal without losing any of my work - it really helps in case of faulty network link that occasionally breaks ssh connections.
Is there something like that available for emacs? Basically, I'd want to be able to:
Detach from emacs and leave it running in background with all the sub-processes ran in term buffers intact.
Reattach to it later and find all my processes running.
Automatic detachment of emacs from terminal on receiving a SIGHUP.
Use emacs daemon:
$ emacs --daemon
Then simply launch a new frame, equivalent for screen -x:
$ emacsclient -t
I'm looking to set up an emacs server such that the files specified by emacsclients
are relative to the emacsclients' filesystem and not the server's filesystem. For instance, if I set up an
emacs server on a machine "darkstar" and I connect to this server through an emacsclient
on "brightstar" with the command
emacsclient -nw '~/fantastic'
The emacs server will attempt to edit the file ~/fantastic on darkstar and not on
brightstar. Id like the reverse of this. I'm open to all sorts of zany suggestions.
*Background note:
I want an emacs process that tracks all the buffers I open on various
machines, keeps track of my color settings, bindings, etc. I want all of this
available and replicated on any arbitrary machine with emacs. The emacs server
seems to do just this but without the ability to edit client's local files!
You should be able to set to set up a shell function which uses tramp, like
edit-local() {
emacsclient -e "(find-file (expand-file-name \"$1\" \"/ssh:$USER#$(hostname):$PWD\"))"
}
Of course you may have to change the tramp protocol to whatever you have setup.
Does the remote machine (the one running Emacs) have mounted the filesystem of the local machine? If so, you could issue something like:
emacsclient --eval ´(my-open-file "~/fantastic" "my-local-machine")´
You could then write the function my-open-file that could, for example, open the file //mounts/my-local-machine/home/YOUR-ACCOUNT/fantastic (assuming this is the mount point).
It will require some elisp-hacking and some script hacking (using, for example, Ruby) to build up the emacsclient command-line.