I remember the controversy with emacs as daemon, emacsclients and friends... hmmm... from a user's perspective I really don't know what I gain by having emacs running as a daemon if I boot up my laptop to say watch a film or listen to a recording from my satellite PVR just for the fun of it. Maybe this sounds like a very old user or a very old and very bad habit (mea maxima culpa) but when I want to edit, I write emacs or emacslient on my CLI or click on the emacs icon or drag-and-drop a file on the emacs icon and then emacs stays alive as long as I want it to stay alive. Because, yes, I do watch films and that is somehow not very compatible with writing (code or whatever). Or am I too monotask? ;-) Best, /PA On Fri, 5 Nov 2021 at 18:52, Ulrich Mueller wrote: > >>>>> On Fri, 05 Nov 2021, Jim Porter wrote: > > > On 11/5/2021 2:40 AM, Ulrich Mueller wrote: > >> $ emacsclient -t --alternate-editor= > >> emacsclient: can't find socket; have you started the server? > >> emacsclient: To start the server in Emacs, type "M-x server-start". > >> Another Emacs daemon is already running at process id 6084 > >> Error: server did not start correctly > >> Error: Could not start the Emacs daemon > >> $ > > > Why are you (or the Gentoo package) running with `--alternate-editor=' > > if a daemon was already started? > > Because the user may not be sure if a daemon is running, and may want to > start it just in case? Which fails with the patch applied. > > Note that the Gentoo package only starts the daemon, calling emacsclient > is up to the user. I'm not keen to receive bug reports because users' > workflows are being broken. (In fact, broken again, as we already had a > round of that with Emacs 27). > > > [...] > > > As for my personal opinion on this, I think it would be best to revert > > bug#33847 (which supports the Gentoo use-case). If necessary, we could > > provide a way to explicitly opt into the (insecure) bug#33847 > > behavior, e.g. by adding a --fall-back-to-tmpdir-sockets flag. I'm > > also ok with my compromise patch, even though it's not perfect. > > Not helpful. :( > > The main problem with XDG_RUNTIME_DIR ist that it doesn't persist > between login sessions: > > | The lifetime of the directory MUST be bound to the user being logged > | in. It MUST be created when the user first logs in and if the user > | fully logs out the directory MUST be removed. [...] Files in the > | directory MUST not survive reboot or a full logout/login cycle. > | > | > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables > > In contrast to that, an Emacs running as a daemon can survive logout, > and the user may want to reconnect to it later. This is impossible if > the socket is located in XDG_RUNTIME_DIR, which is scrapped upon logout. > > In bug #33847 I had suggested to create the socket in ${HOME}/emacs.d/ > instead. Unfortunately this was shot down, with the arguments summarised > in : > > | This would be worse for several reasons: you'd need to disambiguate > | via hostname, you'd need to guarantee hostnames are unique, you'd have > | problems when NFS is flaky or hanging in your home directory, and > | you'd need to deal with socket files that survive OS crashes. > > I still don't think that any of these arguments is substantive: > > - Unix sockets use the file system just as a namespace, which is unique > on any given host. The socket itself is local; there is no sharing > across hosts. Therefore I believe that creating a single socket would > be enough. > > - Flaky NFS shouldn't be a problem, because once the communication is > established, the filesystem is no longer involved in it. (Of course, > there may be NFS problems at the time of startup, but then again, > Emacs cannot read the user's local config either.) > > - A stale socket will just use a single inode, and can be reused the > next time the server is started. > -- Fragen sind nicht da um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler