The emacsclient socket vs. etc/emacs.bash

The emacsclient socket vs. etc/emacs.bash

[Romain Francoise]

I received a bug report stating that newer CVS versions of Emacs no
longer delete their server socket on exit, which causes problems for
users of the `edit' function provided by etc/emacs.bash:

| function edit ()
| {
| [...]
|     # Do not just test if these files are sockets.  On some systems
|     # ordinary files or fifos are used instead.  Just see if they exist.
|     if [ -e "${HOME}/.emacs_server" -o -e "/tmp/emacs${UID}/server" ]; then
|        emacsclient "$@"
|        return $?
|     else
|        echo "edit: starting emacs in background..." 1>&2
|     fi

This function checks for the existence of the socket to decide whether
to call emacsclient or start a new Emacs instance.  Since the socket
remains behind after Emacs exits, it decides to call emacsclient, which
fails (since the latter cannot start a new Emacs itself, yet).

If I understand the recent changes to server.el correctly, Emacs
shouldn't delete the socket on exit, because it might be a socket
started by another Emacs instance and not the original socket.
In that case, isn't it possible to check for the liveness of the socket,
and delete it if it's dead?

(Or perhaps emacs.bash should just do emacsclient -a emacs ...)

Thanks,

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: The emacsclient socket vs. etc/emacs.bash

[Stefan Monnier]

> I received a bug report stating that newer CVS versions of Emacs no
> longer delete their server socket on exit, which causes problems for
> users of the `edit' function provided by etc/emacs.bash:

It's not new in CVS.  Emacs-21.4 doesn't delete his socket either.

> |     # Do not just test if these files are sockets.  On some systems
> |     # ordinary files or fifos are used instead.  Just see if they exist.
> |     if [ -e "${HOME}/.emacs_server" -o -e "/tmp/emacs${UID}/server" ]; then
> |        emacsclient "$@"
> |        return $?
> |     else
> |        echo "edit: starting emacs in background..." 1>&2
> |     fi

Yes, the comment seems partly wrong (I don't think these have ever been
simple files) and if pipes have been used, it must have been before my time,
so this other part of the comment is out of date.  The ~/.emacs_server file
is also an outdated reference, since Emacs doesn't use this one any more.

> This function checks for the existence of the socket to decide whether
> to call emacsclient or start a new Emacs instance.  Since the socket
> remains behind after Emacs exits, it decides to call emacsclient, which
> fails (since the latter cannot start a new Emacs itself, yet).

Indeed, it needs to try and connect before deciding what to do.
That's exactly what would happen if the script relied on the
alternate-editor argument to emacsclient, instead of reinventing the wheel
(tho I guess this probably predates emacsclient's alternate-editor
argument, so it didn't reinvent this wheel).


        Stefan

Re: The emacsclient socket vs. etc/emacs.bash

[Romain Francoise]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It's not new in CVS.  Emacs-21.4 doesn't delete his socket either.

I don't know about Emacs 21, the submitter is comparing to an Emacs from
CVS built a couple of months ago (in which emacs.bash works fine).

And indeed if I revert to revision 1.117 of server.el then Emacs does
remove the socket at exit:

    src$ rm -rf /tmp/emacs1000
    src$ ./emacs --eval '(progn (server-start) (save-buffers-kill-emacs))'
    src$ ls -l /tmp/emacs1000
    total 0
    src$ rm -rf /tmp/emacs1000
    src$ rm ../lisp/server.el*; cvs up ../lisp/server.el # fetch latest
    cvs update: warning: `../lisp/server.el' was lost
    U ../lisp/server.el
    src$ ./emacs --eval '(progn (server-start) (save-buffers-kill-emacs))'
    src$ ls -l /tmp/emacs1000
    total 0
    srwx------ 1 romain romain 0 Dec  8 15:01 server
    src$

This change looks related:

2006-11-02  Stefan Monnier  <monnier@iro.umontreal.ca>

	* server.el (server-auth-key): Remove.  Replace by a process-property.
	(server-start): Don't remove the file of the previous process, but
	instead clear out the place for the new file.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: The emacsclient socket vs. etc/emacs.bash

[Stefan Monnier]

>> It's not new in CVS.  Emacs-21.4 doesn't delete his socket either.
> I don't know about Emacs 21, the submitter is comparing to an Emacs from
> CVS built a couple of months ago (in which emacs.bash works fine).

Yes, the CVS had a code for a short while, where it removed the
socket file.  But it was fixed.

`emacs.bash' is old and hasn't been changed in a long while, so it just
happens that the temporary bug in server.el was hiding a bug in emacs.bash.


        Stefan

Re: The emacsclient socket vs. etc/emacs.bash

[Juanma Barranquero]

On 12/8/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Yes, the CVS had a code for a short while, where it removed the
> socket file.  But it was fixed.

If the Emacs server detects that the server file exists (which means:
another Emacs instance, in the same machine, with the same server
name), it could read its contents and contact the previous Emacs
instance. Then:

 - If it cannot connect, assume it's a leftover and overwrite it
 - If it can connect and the previous Emacs wants to keep it, don't
start the server on the new instance (and warn the user)
 - If it can connect and the previous Emacs relinquishes the server,
overwrite the server file (and the previous instance knows it is not
the server anymore)

It should be relatively simple to implement.

                    /L/e/k/t/u

Re: The emacsclient socket vs. etc/emacs.bash

[Stefan Monnier]

>> Yes, the CVS had a code for a short while, where it removed the
>> socket file.  But it was fixed.

> If the Emacs server detects that the server file exists (which means:
> another Emacs instance, in the same machine, with the same server
> name),

The problem is to remove the socket file when the server quits, because we
don't know for sure that it's still our socket.

> it could read its contents and contact the previous Emacs
> instance. Then:

> - If it cannot connect, assume it's a leftover and overwrite it
> - If it can connect and the previous Emacs wants to keep it, don't
> start the server on the new instance (and warn the user)
> - If it can connect and the previous Emacs relinquishes the server,
> overwrite the server file (and the previous instance knows it is not
> the server anymore)

Yes, that's a possible way to do it better.  But it still will not prevent
leftover socket files in case Emacs exited precipitously.
So it's still preferable for emacs.bash to use the
`alternate-editor' argument.

> It should be relatively simple to implement.

Not so sure since you don't whether whether you're talking (though the
socket) to yourself or to some other process.


        Stefan

Re: The emacsclient socket vs. etc/emacs.bash

[Juanma Barranquero]

On 12/9/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The problem is to remove the socket file when the server quits, because we
> don't know for sure that it's still our socket.

In the method I'm suggesting, each Emacs instance should assume no one
stole its socket (or server file) if it didn't acknowledge and accept
the steal, and in this case, it can remove the file before sending
back the acknowledge. If it ends normally without surrendering the
server status, it just deletes the file.

> Yes, that's a possible way to do it better.  But it still will not prevent
> leftover socket files in case Emacs exited precipitously.

No, but if an instance finds a socket/server-file and no one answers
its request, it can assume the socket is a leftover, because there's
no one listening out there. There's a tiny possibility for a race
condition, but it would still be nicer to the user than the current "I
can assume nothing, so I'll overwrite" method used now.

> Not so sure since you don't whether whether you're talking (though the
> socket) to yourself or to some other process.

I thought the socket name includes the pid of the Emacs instance; the
server-file certainly does, so for TCP sockets it's easy to know.
                    /L/e/k/t/u

Re: The emacsclient socket vs. etc/emacs.bash

[Stefan Monnier]

>> Yes, that's a possible way to do it better.  But it still will not prevent
>> leftover socket files in case Emacs exited precipitously.

> No, but if an instance finds a socket/server-file and no one answers
> its request, it can assume the socket is a leftover, because there's
> no one listening out there. There's a tiny possibility for a race
> condition, but it would still be nicer to the user than the current "I
> can assume nothing, so I'll overwrite" method used now.

I'm not sure which problem you're trying to solve.  I'm talking here about
the problem in emacs.bash which uses the existence of the socket to decide
whether there is a live server or not.

Given the possibility of an Emacs crash leaving a dead socket, this
technique is simply not good enough.  Especially since you'll want to
connect to that socket anyway, so why not first try to connect: if it
succeeds keep on with the actual communication and if it fails then you know
for sure that there's no server available.  That's exactly what the
`alternate-editor' arg does.

>> Not so sure since you don't whether whether you're talking (though the
>> socket) to yourself or to some other process.

> I thought the socket name includes the pid of the Emacs instance; the
> server-file certainly does, so for TCP sockets it's easy to know.

No, the socket name is a "constant" and needs to be constructed without
knowing the process id of the server.  I believe the same holds for the
server-file: the pid is inside the file, not in the file name.  For sockets
we don't have such a place to put this kind of info right now.


        Stefan

Re: The emacsclient socket vs. etc/emacs.bash

[Romain Francoise]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So it's still preferable for emacs.bash to use the `alternate-editor'
> argument.

Is it possible to launch the editor in the background using this
mechanism?

This is an important feature of the emacs.bash script: if the editor
isn't launched in the background then the shell is blocked until the
editor exits.  And on the other hand, we don't want to launch
emacsclient itself in the background because otherwise the user isn't
notified that she hasn't closed the server buffer(s) in Emacs.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: The emacsclient socket vs. etc/emacs.bash

[Richard Stallman]

    If I understand the recent changes to server.el correctly, Emacs
    shouldn't delete the socket on exit, because it might be a socket
    started by another Emacs instance and not the original socket.

Could someone explain how that can make sense?
It seems like asking for trouble not to delete the socket.

Re: The emacsclient socket vs. etc/emacs.bash

[Stefan Monnier]

>     If I understand the recent changes to server.el correctly, Emacs
>     shouldn't delete the socket on exit, because it might be a socket
>     started by another Emacs instance and not the original socket.

> Could someone explain how that can make sense?
> It seems like asking for trouble not to delete the socket.

- time 0: Emacs 1 starts its server.
- time 1: Emacs 2 starts its server, overriding Emacs 1's server.
- time 2: Emacs 1 exits: if it deletes the socket, it actually deletes
  Emacs 2's, not its own, so it'd be a bug

But more concretely, what good would it serve to delete the socket when the
server exits?


        Stefan

Re: The emacsclient socket vs. etc/emacs.bash

[Richard Stallman]

    But more concretely, what good would it serve to delete the socket when the
    server exits?

If the remaining socket can confuse emacsclient, deleting it is a way to
avoid the confusion.

It is true that we can't do this when Emacs crashes.  If that means
emacsclient must be able to cope with the case of a remaining socket
for a dead server, it is not necessary for turning off the server to
delete the socket.  But it is still cleaner to do so.

    - time 0: Emacs 1 starts its server.
    - time 1: Emacs 2 starts its server, overriding Emacs 1's server.

Isn't that already a problem?
Shouldn't we prevent this from happening, somehow?
For instance, make the second server detect this and give an
error message rather than start?

    - time 2: Emacs 1 exits: if it deletes the socket, it actually deletes
      Emacs 2's, not its own, so it'd be a bug

Can Emacs 1 determine that its socket has been replaced?

Re: The emacsclient socket vs. etc/emacs.bash

[Juanma Barranquero]

On 12/9/06, Richard Stallman <rms@gnu.org> wrote:

>     - time 0: Emacs 1 starts its server.
>     - time 1: Emacs 2 starts its server, overriding Emacs 1's server.
>
> Isn't that already a problem?
> Shouldn't we prevent this from happening, somehow?

I agree. I don't like Emacs 2 blindly overwritting Emacs 1's server
(or socket) file.

>     - time 2: Emacs 1 exits: if it deletes the socket, it actually deletes
>       Emacs 2's, not its own, so it'd be a bug
>
> Can Emacs 1 determine that its socket has been replaced?

For local sockets I don't know, but with TCP sockets the server
authentication file contains the pid of the Emacs instance that
created it.

                    /L/e/k/t/u

Re: The emacsclient socket vs. etc/emacs.bash

[Kim F. Storm]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 12/9/06, Richard Stallman <rms@gnu.org> wrote:
>
>>     - time 0: Emacs 1 starts its server.
>>     - time 1: Emacs 2 starts its server, overriding Emacs 1's server.
>>
>> Isn't that already a problem?
>> Shouldn't we prevent this from happening, somehow?
>
> I agree. I don't like Emacs 2 blindly overwritting Emacs 1's server
> (or socket) file.

I hate that too.

I typically have a "master emacs" instance running all the time.
Sometimes I start another instance (e.g. in a terminal window)
just to make some small change to a config file - and blammo - 
the server is no longer associated with the master emacs.

But is this the right time to change this (it's been like that for
ages).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The emacsclient socket vs. etc/emacs.bash

[Juanma Barranquero]

On 12/15/06, Kim F. Storm <storm@cua.dk> wrote:

> But is this the right time to change this (it's been like that for
> ages).

I don't know. Depend on the complexity of the fix, I guess.

                    /L/e/k/t/u

Re: The emacsclient socket vs. etc/emacs.bash

[Stefan Monnier]

>> But is this the right time to change this (it's been like that for
>> ages).

> I don't know. Depend on the complexity of the fix, I guess.

I'd rather we postpone this to post-22.


        Stefan

Re: The emacsclient socket vs. etc/emacs.bash

[Juanma Barranquero]

On 12/16/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I'd rather we postpone this to post-22.

No objection, as long as we make perfectly clear that Emacs
overwriting server files from older instances is a bug to be fixed,
and not a feature.

                    /L/e/k/t/u

Re: The emacsclient socket vs. etc/emacs.bash

[Eli Zaretskii]

> Date: Sat, 16 Dec 2006 00:47:49 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org, "Kim F. Storm" <storm@cua.dk>
> 
> On 12/16/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> > I'd rather we postpone this to post-22.
> 
> No objection, as long as we make perfectly clear that Emacs
> overwriting server files from older instances is a bug to be fixed,
> and not a feature.

We could add an entry to PROBLEMS saying that, and even put Andreas's
.emacs snippet there.

Re: The emacsclient socket vs. etc/emacs.bash

[Juanma Barranquero]

On 12/16/06, Eli Zaretskii <eliz@gnu.org> wrote:

> We could add an entry to PROBLEMS saying that, and even put Andreas's
> .emacs snippet there.

Agreed.

                    /L/e/k/t/u

Re: The emacsclient socket vs. etc/emacs.bash

[Andreas Schwab]

storm@cua.dk (Kim F. Storm) writes:

> I typically have a "master emacs" instance running all the time.
> Sometimes I start another instance (e.g. in a terminal window)
> just to make some small change to a config file - and blammo - 
> the server is no longer associated with the master emacs.

I have this in my .emacs:

(when (and (file-exists-p (expand-file-name server-name server-socket-dir))
	   (let ((status (call-process "/usr/bin/lsof"
				       nil nil nil
				       (expand-file-name server-name
							 server-socket-dir))))
	     (or (not (numberp status)) (equal status 0))))
  (setq server-name (format "%s-%d" server-name (emacs-pid)))
  (add-hook 'kill-emacs-hook
    (lambda () (condition-case nil
		   (delete-file (expand-file-name server-name
						  server-socket-dir))
		 (error nil))))
  (setenv "EDITOR" (concat "emacsclient -s " server-name)))

I regularily have 2 or 3 instances of Emacs running, this way I can
control each of them as necessary.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: The emacsclient socket vs. etc/emacs.bash

[LENNART BORGMAN]

From: storm@cua.dk (Kim F. Storm)
Date: Friday, December 15, 2006 2:37 pm
Subject: Re: The emacsclient socket vs. etc/emacs.bash

> "Juanma Barranquero" <lekktu@gmail.com> writes:
> 
> > On 12/9/06, Richard Stallman <rms@gnu.org> wrote:
> >
> >>     - time 0: Emacs 1 starts its server.
> >>     - time 1: Emacs 2 starts its server, overriding Emacs 1's 
> server.>>
> >> Isn't that already a problem?
> >> Shouldn't we prevent this from happening, somehow?
> >
> > I agree. I don't like Emacs 2 blindly overwritting Emacs 1's server
> > (or socket) file.
> 
> I hate that too.
> 
> I typically have a "master emacs" instance running all the time.
> Sometimes I start another instance (e.g. in a terminal window)
> just to make some small change to a config file - and blammo - 
> the server is no longer associated with the master emacs.
> 
> But is this the right time to change this (it's been like that for
> ages).


This is one of the situation where it might be good to not have anything about server start in the startup files. If emacsclient starts emacs automatically then you do not need that.

Starting another emacs is then safe at least from this point of view.

Re: The emacsclient socket vs. etc/emacs.bash

[Kim F. Storm]

LENNART BORGMAN <lennart.borgman.073@student.lu.se> writes:
>
> This is one of the situation where it might be good to not have
> anything about server start in the startup files. If emacsclient
> starts emacs automatically then you do not need that.

Well, emacs is the first thing I start when I login.
And the last thing I close before I shutdown.

So I don't (ever) need emacsclient to start emacs...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The emacsclient socket vs. etc/emacs.bash

[Lennart Borgman]

Kim F. Storm wrote:
> LENNART BORGMAN <lennart.borgman.073@student.lu.se> writes:
>   
>> This is one of the situation where it might be good to not have
>> anything about server start in the startup files. If emacsclient
>> starts emacs automatically then you do not need that.
>>     
>
> Well, emacs is the first thing I start when I login.
> And the last thing I close before I shutdown.
>
> So I don't (ever) need emacsclient to start emacs...
>   

Maybe you misunderstood what I said? If emacsclient starts emacs the way 
I have proposed then there is no need for the startup files for emacs 
(.emacs etc) to start emacs server. That is taken care of by emacsclient.

If you in such a setup want to start a second emacs then you can just 
start emacs the way you do it today. There will be no trouble with emacs 
server then since the emacs you start this way simply does not care 
about emacs server.

Or, did I misunderstood you?

Re: The emacsclient socket vs. etc/emacs.bash

[Kim F. Storm]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Maybe you misunderstood what I said? If emacsclient starts emacs the
> way I have proposed then there is no need for the startup files for
> emacs (.emacs etc) to start emacs server. That is taken care of by
> emacsclient.
>
> If you in such a setup want to start a second emacs then you can just
> start emacs the way you do it today. There will be no trouble with
> emacs server then since the emacs you start this way simply does not
> care about emacs server.
>
> Or, did I misunderstood you?

I think we mis-communicate...

You talk about emacsclient _starting emacs_ and instructing that emacs
to start the server, so emacsclient can talk to that emacs.  I
understand how that works nicely with e.g. Windows' Explorer and file
associations, and how subsequent calls to emacsclient will talk to
the emacs started by the first emacsclient.

But in my case, I _always_ have emacs running (not started by
emacsclient), so I want emacsclient to talk to that emacs -- how do
you do that without starting the server (e.g. in .emacs) before
running emacsclient?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: The emacsclient socket vs. etc/emacs.bash

[Lennart Borgman]

Kim F. Storm wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>   
>> Maybe you misunderstood what I said? If emacsclient starts emacs the
>> way I have proposed then there is no need for the startup files for
>> emacs (.emacs etc) to start emacs server. That is taken care of by
>> emacsclient.
>>
>> If you in such a setup want to start a second emacs then you can just
>> start emacs the way you do it today. There will be no trouble with
>> emacs server then since the emacs you start this way simply does not
>> care about emacs server.
>>
>> Or, did I misunderstood you?
>>     
>
> I think we mis-communicate...
>
> You talk about emacsclient _starting emacs_ and instructing that emacs
> to start the server, so emacsclient can talk to that emacs.  I
> understand how that works nicely with e.g. Windows' Explorer and file
> associations, and how subsequent calls to emacsclient will talk to
> the emacs started by the first emacsclient.
>
> But in my case, I _always_ have emacs running (not started by
> emacsclient), so I want emacsclient to talk to that emacs -- how do
> you do that without starting the server (e.g. in .emacs) before
> running emacsclient?
>   

Yes, maybe we miscommunicate. I am talking about the suggestions I had 
to change emacsclient (and which I have implemented in a working, but 
not optimal way, in my patched version).

To be able to start "that emacs" I send along the value from emacsclient 
--server-file argument to emacs. No big deal, no changes to emacs 
itself. (I leave out the technical details for now.)

Would it be possible at all for you to start emacs through emacsclient 
this way? Or is something missing that makes it impossible for you?

I am not asking here if you like this way or not. I just want to know if 
it possible. And the second question is of course if you in principle 
would like such an arrangement? I think it has the advantage that I 
mentioned above (and of course the advantage of the automatic startup of 
emacs).

Re: The emacsclient socket vs. etc/emacs.bash

[Kim F. Storm]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Would it be possible at all for you to start emacs through emacsclient
> this way? Or is something missing that makes it impossible for you?

I always run emacs inside gdb ...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk