GNU bug report logs - #1058
23.0.60; emacs --daemon should not return until socket is ready

Previous Next

Package: emacs;

Reported by: SRS0+wOMF+22+gmail.com=trentbuck <at> internode.on.net

Date: Tue, 30 Sep 2008 14:10:04 UTC

Severity: normal

Done: Chong Yidong <cyd <at> stupidchicken.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 1058 <at> debbugs.gnu.org, Romain Francoise <romain <at> orebokech.com>,
        trentbuck <at> gmail.com
Subject: bug#1058: 23.0.60; emacs --daemon should not return until socket is ready
Date: Thu, 02 Oct 2008 17:32:32 -0400
>> I could accept a similar patch, maybe, but first I need to understand
>> why/where we currently "detach" so early.

> Where? in emacs.c:main, look for:
>   if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args))
>     {
> #ifndef DOS_NT
>       pid_t f = fork ();

Oh, thanks.  I somehow overlooked it.

> - in order to not make detaching an elisp function, and have to deal
> with users trying to call it from different contexts
> - the `fork' call for detaching needs to happen before some of the
> initialization is run (although after my 2008-09-28 change it might be
> possible to push it later), and also before .emacs is run and before
> the server is started.

I see what you mean.  But I think forking so early is wrong: all
the --eval and .emacs processing should take place "in the foreground"
with input/output from stdin/stdout (like --batch).

That means that detaching needs indeed to be done late if we want to do
it right.  Of course, that means it's more difficult to implement since
it can be called in many more different contexts (we can/should reject
most of them, but we still need to test/detect the undesirable ones).

I see 3 different solutions:
1 - Someone fixes the code so as to do it right.
2 - we don't touch anything for now postpone the fix to 23.2.
3 - we drop the `fork' for now (so it doesn't behave like an actual
    daemon, more like a --batch); waiting for a `daemonize' Elisp
    function to be added in 23.2.

I'm not sure if 1 can be done in a way appropriate for 23.1.
What happens to messages resulting from executing .emacs in solution nb
2 are they sent to stdout or are they silently dropped?


        Stefan


PS: Currently "emacs --daemon" doesn't do anything for me: it
immediately (as in "I've never seen Emacs start or stop so fast")
returns with no output and no remaining process.




This bug report was last modified 16 years and 201 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.