Lost socket for detached Emacs, how to regain control?

Lost socket for detached Emacs, how to regain control?

[Ulrich Mueller]

Consider the following scenario:
  - emacs --daemon is running in the background without any open frame
  - server-start is also called in another Emacs process

Now there is no more way to connect to the detached Emacs. (Or am I
missing something?)

Maybe it would be feasible to add a recovery mechanism for such a
case, like binding [sigusr1] to server-start?

Ulrich

Re: Lost socket for detached Emacs, how to regain control?

[Stefan Monnier]

> Consider the following scenario:
>   - emacs --daemon is running in the background without any open frame
>   - server-start is also called in another Emacs process

> Now there is no more way to connect to the detached Emacs. (Or am I
> missing something?)

> Maybe it would be feasible to add a recovery mechanism for such a
> case, like binding [sigusr1] to server-start?

That would be easy to do, indeed.  Another option is for server-start to
try and detect that there's already an active socket (using
server-running-p) and refuse to start.


        Stefan

Re: Lost socket for detached Emacs, how to regain control?

[Juanma Barranquero]

On Thu, Nov 6, 2008 at 02:31, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Another option is for server-start to
> try and detect that there's already an active socket (using
> server-running-p) and refuse to start.

That would be useful even for local servers using TCP sockets, but
server-running-p currently does work only for local sockets.

The following is a simple way to at least know whether there's a
process called Emacs with the same pid that is stored in the
authentication file.

(with-temp-buffer
  (insert-file-contents-literally (expand-file-name server-name
server-auth-dir))
  (skip-chars-forward "0-9:.")
  (let ((case-fold-search t)
        (proc (assq 'comm (system-process-attributes (read (point-marker))))))
    (and proc
         (string-match-p "emacs" (cdr proc)))))

  Juanma

Re: Lost socket for detached Emacs, how to regain control?

[Stefan Monnier]

>> Another option is for server-start to try and detect that there's
>> already an active socket (using server-running-p) and refuse
>> to start.

> That would be useful even for local servers using TCP sockets, but
> server-running-p currently does work only for local sockets.

Indeed, for TCP sockets it would be useful as well, but it risks
suffering from a long timeout.

> The following is a simple way to at least know whether there's a
> process called Emacs with the same pid that is stored in the
> authentication file.

That's a good alternative, tho it should check somehow that the server
is supposed to run on the same machine.


        Stefan

Re: Lost socket for detached Emacs, how to regain control?

[Juanma Barranquero]

On Thu, Nov 6, 2008 at 15:15, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> That's a good alternative, tho it should check somehow that the server
> is supposed to run on the same machine.

The simplest way to do it without any networking (and so, without
risking delays) is just checking that the address in the server auth
file is 127.0.0.1.

But I have a doubt. What is the intended use of `server-running-p'?
That affects whether to check for local sockets, TCP sockets, or both.

   Juanma

Re: Lost socket for detached Emacs, how to regain control?

[Stefan Monnier]

>> That's a good alternative, tho it should check somehow that the server
>> is supposed to run on the same machine.

> The simplest way to do it without any networking (and so, without
> risking delays) is just checking that the address in the server auth
> file is 127.0.0.1.

> But I have a doubt. What is the intended use of `server-running-p'?
> That affects whether to check for local sockets, TCP sockets, or both.

Currently it's not used (except in some people's .emacs).  The intended
use is in start-server to try and prevent hijacking the socket of
a pre-existing server.  So it's probably not less important for TCP where
two servers of the same name can actually co-exist on different ports.


        Stefan

Re: Lost socket for detached Emacs, how to regain control?

[Juanma Barranquero]

On Fri, Nov 7, 2008 at 03:15, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Currently it's not used (except in some people's .emacs).  The intended
> use is in start-server to try and prevent hijacking the socket of
> a pre-existing server.  So it's probably not less important for TCP where
> two servers of the same name can actually co-exist on different ports.

But, you cannot have two TCP servers co-existing with the same name on
the same computer unless you customize `server-auth-dir' with
different values in each instance.

At that point, how do you direct `server-running-p' to decide what
director(y|ies) to look for?

  Juanma

Re: Lost socket for detached Emacs, how to regain control?

[Ulrich Mueller]

>>>>> On Wed, 05 Nov 2008, Stefan Monnier wrote:

>> Consider the following scenario:
>> - emacs --daemon is running in the background without any open frame
>> - server-start is also called in another Emacs process

>> Now there is no more way to connect to the detached Emacs. (Or am I
>> missing something?)

>> Maybe it would be feasible to add a recovery mechanism for such a
>> case, like binding [sigusr1] to server-start?

> That would be easy to do, indeed.  Another option is for server-start
> to try and detect that there's already an active socket (using
> server-running-p) and refuse to start.

Or both? The server process or socket could be non-functional for other
reasons.

In case server-start is changed, maybe an option to force a restart
should be added.

Ulrich

Re: Lost socket for detached Emacs, how to regain control?

[Stefan Monnier]

>>> Maybe it would be feasible to add a recovery mechanism for such a
>>> case, like binding [sigusr1] to server-start?
>> That would be easy to do, indeed.  Another option is for server-start
>> to try and detect that there's already an active socket (using
>> server-running-p) and refuse to start.
> Or both? The server process or socket could be non-functional for other
> reasons.

If you want.  I don't find the feature of "sigusr1 causes
server-restart" very useful, since in the rare remaining cases where the
problem may happen, you may as well kill the server process altogether
and start a new one.  But I wouldn't care to oppose it either.


        Stefan

Re: Lost socket for detached Emacs, how to regain control?

[Dan Nicolaescu]

Ulrich Mueller <ulm@gentoo.org> writes:

  > >>>>> On Wed, 05 Nov 2008, Stefan Monnier wrote:
  > 
  > >> Consider the following scenario:
  > >> - emacs --daemon is running in the background without any open frame
  > >> - server-start is also called in another Emacs process
  > 
  > >> Now there is no more way to connect to the detached Emacs. (Or am I
  > >> missing something?)
  > 
  > >> Maybe it would be feasible to add a recovery mechanism for such a
  > >> case, like binding [sigusr1] to server-start?
  > 
  > > That would be easy to do, indeed.  Another option is for server-start
  > > to try and detect that there's already an active socket (using
  > > server-running-p) and refuse to start.
  > 
  > Or both? The server process or socket could be non-functional for other
  > reasons.

Like a silly cron job removing the socket from /tmp.  I've had a
[sigusr2] binding to server-start in my .emacs for a long time for
exactly that reason.  It has been very useful quite a few times.