remote emacs client connects, but doesn't create new frame in terminal - emacs

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.

Related

Mobaxterm: how to prevent ssh session from exiting?

How do i stop this?
Session stopped
- Press <return> to exit tab
- Press R to restart session
- Press S to save terminal output to file
Network error: Software caused connection abort
It looks SSH keepalive setting has no effect there
If you are still looking for the answer like me, here you go!
Settings -> Configuration -> SSH -> SSH keepalive
Restart MobaXTerm after changing the setting for it to take effect.
https://superuser.com/a/1298536
In my case I have SSH keepalive option checked but this happens every now and then.
So what I do is.
Disable (uncheck) SSH keeaplive close MobaXterm
Open MobaXterm and check SSH keeaplive close MobaXterm (again)
Open MobaXterm enjoy the stability for a couple of weeks...
I am using a licensed version on a computer running Windows 10 Professinal version 20H2.
Both solutions posted above (by #helloworld & #jepachecoh) actually work but there may be need for extra work, so here are a few additions.
The two options above work if:
1. You're connecting to a host (destination server) that is running SSH (daemon) but doesn't have any session timeout configurations set for connecting SSH clients.
2. You're connecting to a host that already has SSH client timeout configuration set but the set value (on the remote host) is either higher than, or equal to the "keepalive" value you have set on your SSH client (like MobaXterm, Putty etc).
If the destination server's "SSH keepalive configurations for the clients" are set, they override your remote client SSH keepalive configurations, hence controlling the session timeouts.
To find out if there are any configs set on the destination server's SSH configurations, use the command below (as root, or a user with sudo privileges):
$ cat /etc/ssh/sshd_config | grep "ClientAlive"
The command above works on multiple Linux and Solaris flavours.
If you don't have admin access to the destination server, your Systems administrator may be managing your session timeouts irrespective of the "keepalive" parameters you set on your SSH client before connecting.
Lastly, if you are using VPN software, or connecting to a demilitarized zone (DMZ), sometimes the session timeouts are controlled at that level (firewall level), so involve your Network administrator.
Bottom line, love your administrators. :-)

Attach an emacsclient to a specified running emacs server

Multiple named emacs servers might be invoked by the the commands
{
emacs --daemon="test1"
emacs --daemon="test2"
emacs --daemon='test3"
} &> /dev/null
As there are three emacs server running on background,
How could attach an emacsclient to a specified one , saying "test2"?
From https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html:
The emacsclient program can specify a server by name, using the ‘-s’
or the ‘-f’ option (see emacsclient Options), depending on whether or
not the server uses a TCP socket (see TCP Emacs server).

Emacs-Tramp: Not working properly

I'm trying to use Tramp/Emacs-23 in Ubuntu 12.04 in order to edit the remote host files. My remote host has two step authentication (RSA+Passwd). I use multiplexing through .ssh/config to ensure that tramp can directly connect to the remote shell without having to provide passwords.
My problem however is that I have 3 different remote hosts. When I try to connect to remote host through tramp without the initial multiplexing (through terminal), the TRAMP hangs with a message stating "Tramp: Waiting for prompts from remote shell". I used the below mentioned commands in .ssh/config to ensure the connection gets lost after a specified interval upon no prompt.
Host *
ServerAliveCountMax=30
ServerAliveInterval=5
However this doesn't seem to have any effect on the tramp connection. It will be of help if someone can help me in fixing this issue.
Sorry that your question has been left hanging so long.
I can offer a couple of things to try, use the tramp protocol sshx instead of ssh, it seems to cope better with most non-vanilla ssh connections.
e.g.
/sshx:user#host:path/filename
The other thing to try is adding your ssh key passphrase to the session at startup, run an ssh-agent on the machine, and connect to it at startup, then run ssh-add to enter the passphrase once.
As a side note, upgrade your Emacs to 24.3 there's a lot of new/great stuff in there since 23.x

Detaching and Re-attaching to Emacs server

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.

Can Emacs server edit remote files specified by Emacs client?

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.