connecting to a lost server process

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

connecting to a lost server process

Madhu-8
I'm having problems with the behaviour of emacs --daemon.  Under some
circumstances when the emacsclient -t dies (say when the GNU screen
dungeon collapses), The server file and server directory gets
unexpectedly deleted.  In this case the server is left running but one
cannot connect to it.

The socket is still open as can be seen in /proc/<emacspid>/fd/ - is
there some linux arcana that can be exploited to connect to it?

Earlier it used to be possible to gdb attach to the emacs process and
to restart the server. Something like
Feval(Fcar(Fread_from_string(build_string("(server-start)"),Qnil,Qnil)),Qnil)
But for some time now that route hits a
terminate_due_to_signal. (Apparently make-network-process tries to
signal an error which calls emacs_abort which ends the show)

[Unfortunately recently the robustness of the server mechanism has gone
down - (especially since elogind).  Typically I set
XDG_RUNTIME_DIR=/dev/shm/<username> in my environment and start a
server which i expect to survive restarts in dbus, elogind etc.  That
seems no longer possible even when using a --without-x emacs.]




Reply | Threaded
Open this post in threaded view
|

Re: connecting to a lost server process

Eli Zaretskii
> Date: 12 Jul 2019 06:20:57 -0000
> From: Madhu <[hidden email]>
>
> The socket is still open as can be seen in /proc/<emacspid>/fd/ - is
> there some linux arcana that can be exploited to connect to it?
>
> Earlier it used to be possible to gdb attach to the emacs process and
> to restart the server. Something like
> Feval(Fcar(Fread_from_string(build_string("(server-start)"),Qnil,Qnil)),Qnil)
> But for some time now that route hits a
> terminate_due_to_signal. (Apparently make-network-process tries to
> signal an error which calls emacs_abort which ends the show)

Please report a bug with the details of that crash, it may or may not
be a bug.

> [Unfortunately recently the robustness of the server mechanism has gone
> down - (especially since elogind).  Typically I set
> XDG_RUNTIME_DIR=/dev/shm/<username> in my environment and start a
> server which i expect to survive restarts in dbus, elogind etc.  That
> seems no longer possible even when using a --without-x emacs.]

Did you try to bind a function to sigusr1 or sigusr2 event, and have
that function restore the server file?