I have a desktop always running at work with Emacs open. I'd like to remotely connect to the process on my computer at work, and am able to do that with ssh and emacsclient. But I can't cleanly exit without causing the original process to crash. I'm doing the following to connect to an emacs frame with a server name of 'foo':
$ ssh -XC ej#tower
$ emacsclient -s foo -e "(make-frame-on-display \"$DISPLAY\")"
This works, however I can't find any way to kill the ssh connection without crashing the original process. It seems like some background process is still connected, and killing it (which occurs after killing the remote connection) brings down everything. Does anyone know a better way to do this or a way ?
I know what you're talking about, and rather curiously I can't recreate it on my current system. I'm not sure why that is. However...
The classic workaround to avoid this is to start processes in a sub-shell:
$ (emacs &)
rather than:
$ emacs &
There are also things like nohup and disown which you may or may not have available, but the sub-shell approach is simple and has always been reliable for me.
You could also start the processes from the local side of the connection:
$ ssh -XC ej#tower -f emacs --daemon=foo
$ ssh -XC ej#tower -f emacsclient -s foo -c
The issue I was running into stemmed from a Gtk+ bug which caused Emacs to crash when an X11 connection was unexpectedly lost.
Recompiling to use a different X toolkit solved the issue.
./configure --with-x-toolkit=lucid
Related
I'm running VS Code on Windows, and SSH into a Ubuntu machine.
Executing killall node and sending the command to the remote machine causes the local VS Code instance to require restart - Presumably to rebind the SSH connection locally(?).
This is bad for workflow.
Is there a better way to kill all node processes on the remote machine without destroying VD Code requiring to reconnect?
lsof -i -P -n | grep LISTEN reveals that we might be able to get away with just killing IPv6-bound processes - Can these be targeted as a group (Somehting like killall node ipv6)?
A note that killall node is the only way ensure the node process is killed and a port conflict doesn't arise. Every other conceivable method, kill -9 on the process etc, both on the command line and in the code base through SIGINT have been tried.
Suggesting to try commands pkill and learn about pgrep on remote machine.
pkill -9 -f node
Also suggesting to write a bash script:
nodes_killer
#!/bin/bash
killall node
Than give nodes_killer execution permissions
chmod a+x nodes_killer
Than try to call nodes_killer remotely.
This might guard your VSC from the killall command.
What exactly does command sudo setsebool -P nis_enabled 1 ? It seems to fixed strange access denied errors when running rabbitmq on Centos 7. All I know is that it i somehow related to SELINUX (what is for me black magic and often the reason why various programs mysteriously does not run).
I Guess NIS=Network Information Service
Earlier this week I tried ssh'ing into my lab machine (as I do very frequently) via tramp mode (ubuntu 14.04) and now it seems to not work out of the blue. I have tried checking all folder permissions, that ssh actually works (in terminal, even nested in emacs). However, it still will not connect me. I see the connection in my .ssh file so I am not sure what the issue is. Any ideas? This is killing my productivity since I would much rather tramp in vs git everything.
######### from C-x C-f ssh:user#host...etc (which has always worked in the past) #######
ssh: Could not resolve hostname ssh: Name or service not known
########## from *Messages buffer* #####################
Tramp: Opening connection for ssh using scp...
Tramp: Sending command `exec ssh -e none ssh'
Tramp: Waiting for prompts from remote shell
Tramp: Sending command `exec ssh -e none ssh'
Tramp: Opening connection for ssh using scp...done
byte-code: Process died
side note: I did start having pop-ups w/ system program problem detected but the ONLY thing in the /var/crash folder is a virtual box issue so I cant imagine that could be it. (Can I purge emacs and grab my config again and solve it that way?)
The error message clearly indicates that you are doing C-x C-f /ssh:user#host/path/to/file. A colon is missing after host. Pls open this like C-x C-f /ssh:user#host:/path/to/file.
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
When I start the `Paste' web server in daemon mode, it seems to kill off it's ability to reload when the timestamp of a source file is updated.
Here is how I start the daemon...
cd ${project} && ../bin/paster serve --reload --daemon development.ini; cd ..;
...which defeats one of the main points of using Paste (for me).
Has anyone come across this or know what I'm doing wrong?
To be complete, the file that I'm changing is a controller file.
The version is `PasteScript 1.7.3'
I believe that the two options are essentially incompatible, since the reloader stops the server with a SIGTERM and the daemon-ized server is impervious to that -- and since daemon is intended for running in a production environment, and reload for a development/debugging environment, I guess that their incompatibility is not seen as a big loss. I imagine a customized reloader, tailored to properly stop and restart the daemonized server, could certainly be developed, but I don't know of any existing one.
I had a similar problem and circumvented the problem. I currently have paster running on a remote host, but I am still developing, so I needed a means to restart paster, but manually by hand was too time consuming, and daemon didnt work. So I always had to keep a shell window open to the server and running paster without --daemon in there. Once I finished my work for that day, and i closed the shell, paster died, which is bad.
I circumvented that by running paster non daemonized in a "screen".
Simply type "screen" in your shell of choice, you will usually depending on your linux be presented with a virtual terminal, that will keep running even when you log out your remote session. Start paster as usually in your new "window" (the screen) with --reload but without daemon, and then detach the window, so you can return to your normal shell (detach = CTRL-A, then press D). You can re-enter that screen by typing "screen -r". If you would like to kill it, reconnect it (screen -r) and inside the screen type CTRL-A, then press K.
Hope that helps.