bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[SRS0+wOMF+22+gmail.com=trentbuck]

From this transcript, you can see that after starting 'emacs
--daemon', it takes five seconds before the socket is actually
available for emacsclient to talk to it.

    $ emacs --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done
    emacs: no process killed
    ls: cannot access /tmp/emacs1187/: No such file or directory
    ls: cannot access /tmp/emacs1187/: No such file or directory
    ls: cannot access /tmp/emacs1187/: No such file or directory
    ls: cannot access /tmp/emacs1187/: No such file or directory
    server

This is evil; it means that making $ALTERNATE_EDITOR a script that
just does

    emacs --daemon && emacsclient

results in a loop, because the socket isn't ready when emacsclient
starts -- so emacsclient runs the above script again.  For --daemon to
be useful to me, it really must not exit until the socket is ready.

A filthy workaround might look something like this.

    #!/bin/bash -e
    emacs --daemon
    while ! test -e /tmp/emacs$EUID/server
    do sleep 1
    done
    emacsclient
  






In GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11)
 of 2008-09-28 on elegiac, modified by Debian
 (emacs-snapshot package, version 1:20080928-1)
configured using `configure  '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/23.0.60/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.0.60/site-lisp:/usr/share/emacs/site-lisp' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 'LDFLAGS=-g -Wl,--as-needed' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC x r e p o r t SPC e m a c s SPC b u TAB RET

Recent messages:
("emacs" "-Q")
For information about GNU Emacs and the GNU system, type C-h C-a.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

SRS0+wOMF+22+gmail.com=trentbuck@internode.on.net writes:

  > From this transcript, you can see that after starting 'emacs
  > --daemon', it takes five seconds before the socket is actually
  > available for emacsclient to talk to it.
  > 
  >     $ emacs --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done

Just curious, what do you get if you do:

emacs -Q --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done


  >     emacs: no process killed
  >     ls: cannot access /tmp/emacs1187/: No such file or directory
  >     ls: cannot access /tmp/emacs1187/: No such file or directory
  >     ls: cannot access /tmp/emacs1187/: No such file or directory
  >     ls: cannot access /tmp/emacs1187/: No such file or directory
  >     server
  > 
  > This is evil; it means that making $ALTERNATE_EDITOR a script that
  > just does
  > 
  >     emacs --daemon && emacsclient
  > 
  > results in a loop, because the socket isn't ready when emacsclient
  > starts -- so emacsclient runs the above script again.  For --daemon to
  > be useful to me, it really must not exit until the socket is ready.

Unfortunately ATM I don't see an easy way to do that.  Ideas/patches are
certainly welcome.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Romain Francoise]

Hi Dan, Trent,

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Just curious, what do you get if you do:
> emacs -Q --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done

Yes, the delay is caused by my change to load the init file before
starting the server.

> Unfortunately ATM I don't see an easy way to do that.
> Ideas/patches are certainly welcome.

It's easy to do, but not very clean.  WDYT?


diff --git a/lisp/startup.el b/lisp/startup.el
index 5bd73f9..d9e37be 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -1224,7 +1224,8 @@ opening the first frame (e.g. open a connection to an X server).")
   ;; processing all command line arguments to allow e.g. `server-name'
   ;; to be changed before the server starts.
   (when (daemonp)
-    (server-start))
+    (server-start)
+    (daemon-detach-parent))
 
   ;; Run emacs-session-restore (session management) if started by
   ;; the session manager and we have a session manager connection.
diff --git a/src/emacs.c b/src/emacs.c
index f94d2d3..a2842d4 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -235,6 +235,10 @@ int noninteractive1;
 /* Nonzero means Emacs was started as a daemon.  */
 int is_daemon = 0;
 
+/* Pipe used to send exit notification to the daemon parent at
+   startup.  */
+int daemon_pipe[2];
+
 /* Save argv and argc.  */
 char **initial_argv;
 int initial_argc;
@@ -1074,16 +1078,31 @@ main (int argc, char **argv)
   if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args))
     {
 #ifndef DOS_NT
+      if (pipe (daemon_pipe) == -1)
+	{
+	  fprintf (stderr, "Cannot pipe!\n");
+	  exit (1);
+	}
       pid_t f = fork ();
       int nfd;
       if (f > 0)
-	exit (0);
+	{
+	  char buf[2];
+	  close (daemon_pipe[1]);
+	  /* Wait for the child to close its end of the pipe before
+	     exiting.  */
+	  while (read (daemon_pipe[0], &buf, 1) < 0)
+	    sleep (0.1);
+	  close (daemon_pipe[0]);
+	  exit (0);
+	}
       if (f < 0)
 	{
 	  fprintf (stderr, "Cannot fork!\n");
 	  exit (1);
 	}
 
+      close (daemon_pipe[0]);
       nfd = open ("/dev/null", O_RDWR);
       dup2 (nfd, 0);
       dup2 (nfd, 1);
@@ -2389,6 +2408,16 @@ DEFUN ("daemonp", Fdaemonp, Sdaemonp, 0, 0, 0,
   return is_daemon ? Qt : Qnil;
 }
 
+DEFUN ("daemon-detach-parent", Fdaemon_detach_parent, Sdaemon_detach_parent,
+       0, 0, 0,
+       doc: /* Detach Emacs from its invocation parent if it was started as a daemon.  */)
+  ()
+{
+  if (is_daemon)
+    close (daemon_pipe[1]);
+  return Qt;
+}
+
 void
 syms_of_emacs ()
 {
@@ -2408,6 +2437,7 @@ syms_of_emacs ()
   defsubr (&Sinvocation_name);
   defsubr (&Sinvocation_directory);
   defsubr (&Sdaemonp);
+  defsubr (&Sdaemon_detach_parent);
 
   DEFVAR_LISP ("command-line-args", &Vcommand_line_args,
 	       doc: /* Args passed by shell to Emacs, as a list of strings.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Andreas Schwab]

Romain Francoise <romain@orebokech.com> writes:

> +	  while (read (daemon_pipe[0], &buf, 1) < 0)
> +	    sleep (0.1);

sleep takes an integer, not a float.

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."

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Hi Dan, Trent,
  > 
  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Just curious, what do you get if you do:
  > > emacs -Q --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done
  > 
  > Yes, the delay is caused by my change to load the init file before
  > starting the server.
  > 
  > > Unfortunately ATM I don't see an easy way to do that.
  > > Ideas/patches are certainly welcome.
  > 
  > It's easy to do, but not very clean.  WDYT?

It would be much better if this could be done without a state changing
function callable from elisp.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Trent W. Buck]

On Wed, Oct 01, 2008 at 09:51:10AM -0700, Dan Nicolaescu wrote:
>> From this transcript, you can see that after starting 'emacs
>> --daemon', it takes five seconds before the socket is actually
>> available for emacsclient to talk to it.
>>
>>   $ emacs --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done
>
> Just curious, what do you get if you do:
>
> emacs -Q --daemon; while ! ls /tmp/emacs1187/; do sleep 1; done

I get the same problem.  Running c++ elsewhere and starting Emacs
nicely, I managed to get the delay up to 17 seconds.

$ nice -n 19 emacs -Q --daemon; until ls /tmp/emacs1187/; do sleep 1; done
ls: cannot access /tmp/emacs1187/: No such file or directory
[repeats 16 times]
server

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Trent W. Buck]

On Wed, Oct 01, 2008 at 09:39:40PM +0200, Romain Francoise wrote:
>> Just curious, what do you get if you do: emacs -Q --daemon; while !
>> ls /tmp/emacs1187/; do sleep 1; done
>
> Yes, the delay is caused by my change to load the init file before
> starting the server.

It's vaguely relevant that I have this in my .emacs:

  (progn
    (unless (< emacs-major-version 22)
      ;; Support multiple, concurrent Emacs servers.
      (setq server-name (format "server%d" (emacs-pid)))
      ;; Allow child processes to find the correct one.
      (setenv "EMACS_SOCKET_FILE" server-name)
      ;; Have other processes use the youngest server.
      (defadvice server-start (after multiple-server-start)
        (make-symbolic-link server-name
                            (concat server-socket-dir "/server")
                            t))
      (ad-activate 'server-start))
    (server-start))

and an emacsclient wrapper that includes

    ## In M-x shell always use the focused emacs, even if there are
    ## other Emacs servers.  Requires non-standard $EMACS_SOCKET_FILE,
    ## which is set in my .emacs.  Needs Emacs 22 or better.
    if [[ $EMACS_SOCKET_FILE && $INSIDE_EMACS && $v -ge 22 ]]
    ## With DISPLAY emacsclient tries to pop up an X frame.
    then exec env -u DISPLAY emacsclient -s "$EMACS_SOCKET_FILE" "$@"
    fi

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Romain Francoise]

Andreas Schwab <schwab@suse.de> writes:

> sleep takes an integer, not a float.

Hrm, yeah.  And the detach function should be guarded otherwise it
would close random fds on each call, which is probably not what we
want.  And the while-sleep loop should be done differently.

But anyway, this was just a quick proof of concept, it happened to
compile and work on the first try, so...

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Romain Francoise]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> It would be much better if this could be done without a state
> changing function callable from elisp.

I agree, but given that control passes to Lisp pretty early, I don't
see how it can be done.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > It would be much better if this could be done without a state
  > > changing function callable from elisp.
  > 
  > I agree, but given that control passes to Lisp pretty early, I don't
  > see how it can be done.

That's exactly the reason for my initial reply...

Anyway, your patch probably needs an approval from a maintainer.

And a better name and docstring for daemon-detach-parent would be
needed.
Also daemon-detach-parent should throw an error if called in the non-daemon
case, and when called more than once.
More comments explaining what's going on would also be nic.
Maybe use select instead of read+sleep?
Or signals?
Should also do something in case the child dies before it calls
daemon-detach-parent.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Stefan Monnier]

>> > It would be much better if this could be done without a state
>> > changing function callable from elisp.
>> I agree, but given that control passes to Lisp pretty early, I don't
>> see how it can be done.
> That's exactly the reason for my initial reply...
> Anyway, your patch probably needs an approval from a maintainer.

I could accept a similar patch, maybe, but first I need to understand
why/where we currently "detach" so early.


        Stefan

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

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

  > >> > It would be much better if this could be done without a state
  > >> > changing function callable from elisp.
  > >> I agree, but given that control passes to Lisp pretty early, I don't
  > >> see how it can be done.
  > > That's exactly the reason for my initial reply...
  > > Anyway, your patch probably needs an approval from a maintainer.
  > 
  > 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 ();

Why?
- mainly because I never thought about the emacs --daemon && emacsclient use-case.
- 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.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Romain Francoise]

Here's version one of a patch for this, please let me know what you
think.

diff --git a/lisp/startup.el b/lisp/startup.el
index 5bd73f9..22c92c5 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -1224,7 +1224,8 @@ opening the first frame (e.g. open a connection to an X server).")
   ;; processing all command line arguments to allow e.g. `server-name'
   ;; to be changed before the server starts.
   (when (daemonp)
-    (server-start))
+    (server-start)
+    (daemon-initialized))
 
   ;; Run emacs-session-restore (session management) if started by
   ;; the session manager and we have a session manager connection.
diff --git a/src/emacs.c b/src/emacs.c
index f94d2d3..d4d16b7 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -235,6 +235,13 @@ int noninteractive1;
 /* Nonzero means Emacs was started as a daemon.  */
 int is_daemon = 0;
 
+/* Set nonzero after the daemon has finished initializing.  */
+int daemon_initialized = 0;
+
+/* Pipe used to send exit notification to the daemon parent at
+   startup.  */
+int daemon_pipe[2];
+
 /* Save argv and argc.  */
 char **initial_argv;
 int initial_argc;
@@ -1074,16 +1081,56 @@ main (int argc, char **argv)
   if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args))
     {
 #ifndef DOS_NT
-      pid_t f = fork ();
+      pid_t f;
       int nfd;
+
+      /* Start as a daemon: fork a new child process which will run the
+	 rest of the initialization code, then exit.
+
+	 We want to avoid exiting before the server socket is ready, so
+	 use a pipe for synchronization.  The parent waits for the child
+	 to close its end of the pipe (using `daemon-initialized')
+	 before exiting.  */
+      if (pipe (daemon_pipe) == -1)
+	{
+	  fprintf (stderr, "Cannot pipe!\n");
+	  exit (1);
+	}
+
+      f = fork ();
       if (f > 0)
-	exit (0);
+	{
+	  int retval;
+	  char buf[1];
+
+	  /* Close unused writing end of the pipe.  */
+	  close (daemon_pipe[1]);
+
+	  /* Just wait for the child to close its end of the pipe.  */
+	  do
+	    {
+	      retval = read (daemon_pipe[0], &buf, 1);
+	    }
+	  while (retval == -1 && errno == EINTR);
+
+	  if (retval < 0)
+	    {
+	      fprintf (stderr, "Error reading status from child\n");
+	      exit (1);
+	    }
+
+	  close (daemon_pipe[0]);
+	  exit (0);
+	}
       if (f < 0)
 	{
 	  fprintf (stderr, "Cannot fork!\n");
 	  exit (1);
 	}
 
+      /* Close unused reading end of the pipe.  */
+      close (daemon_pipe[0]);
+
       nfd = open ("/dev/null", O_RDWR);
       dup2 (nfd, 0);
       dup2 (nfd, 1);
@@ -2389,6 +2436,24 @@ DEFUN ("daemonp", Fdaemonp, Sdaemonp, 0, 0, 0,
   return is_daemon ? Qt : Qnil;
 }
 
+DEFUN ("daemon-initialized", Fdaemon_initialized, Sdaemon_initialized, 0, 0, 0,
+       doc: /* Mark the Emacs daemon as being initialized.  */)
+  ()
+{
+  if (is_daemon)
+    {
+      if (! daemon_initialized)
+	{
+	  /* Closing the pipe will notify the parent that it can exit. */
+	  close (daemon_pipe[1]);
+	  daemon_initialized = 1;
+	}
+    }
+  else
+    error ("Emacs was not started as a daemon");
+  return daemon_initialized ? Qt : Qnil;
+}
+
 void
 syms_of_emacs ()
 {
@@ -2408,6 +2473,7 @@ syms_of_emacs ()
   defsubr (&Sinvocation_name);
   defsubr (&Sinvocation_directory);
   defsubr (&Sdaemonp);
+  defsubr (&Sdaemon_initialized);
 
   DEFVAR_LISP ("command-line-args", &Vcommand_line_args,
 	       doc: /* Args passed by shell to Emacs, as a list of strings.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Here's version one of a patch for this, please let me know what you
  > think.


Looks good to me (assuming it works), I found some nits:


  > @@ -1224,7 +1224,8 @@ opening the first frame (e.g. open a connection to an X server).")
  >    ;; processing all command line arguments to allow e.g. `server-name'
  >    ;; to be changed before the server starts.
  >    (when (daemonp)
  > -    (server-start))
  > +    (server-start)
  > +    (daemon-initialized))

Maybe "notify-daemon-initialized"?

  >    ;; Run emacs-session-restore (session management) if started by
  >    ;; the session manager and we have a session manager connection.
  > diff --git a/src/emacs.c b/src/emacs.c
  > index f94d2d3..d4d16b7 100644
  > --- a/src/emacs.c
  > +++ b/src/emacs.c
  > @@ -235,6 +235,13 @@ int noninteractive1;
  >  /* Nonzero means Emacs was started as a daemon.  */
  >  int is_daemon = 0;
  >  
  > +/* Set nonzero after the daemon has finished initializing.  */
  > +int daemon_initialized = 0;

Make it a static inside the only user?

  > +/* Pipe used to send exit notification to the daemon parent at
  > +   startup.  */
  > +int daemon_pipe[2];
  > +
  >  /* Save argv and argc.  */
  >  char **initial_argv;
  >  int initial_argc;
  > @@ -1074,16 +1081,56 @@ main (int argc, char **argv)
  >    if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args))
  >      {
  >  #ifndef DOS_NT
  > -      pid_t f = fork ();
  > +      pid_t f;
  >        int nfd;
  > +
  > +      /* Start as a daemon: fork a new child process which will run the
  > +	 rest of the initialization code, then exit.

The child runs everything, not only the initialization.  
Maybe say "exit in order to detach from the terminal" or some such?

  > +DEFUN ("daemon-initialized", Fdaemon_initialized, Sdaemon_initialized, 0, 0, 0,
  > +       doc: /* Mark the Emacs daemon as being initialized.  */)
  > +  ()
  > +{
  > +  if (is_daemon)
  > +    {
  > +      if (! daemon_initialized)
  > +	{
  > +	  /* Closing the pipe will notify the parent that it can exit. */
  > +	  close (daemon_pipe[1]);
  > +	  daemon_initialized = 1;
  > +	}

       else error ("Can only do this once");
    

BTW, ideally the parent would exit when it detects that the server is
started, but that's much more complicated to implement...

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Stefan Monnier]

>> 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.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > > - 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).

Is that desirable?  We seem to be looking at this from different points
of view.  I want the daemon to start the server early, and that should
be the only way to interact with it.  You want to have a full blown
emacs until the server is started...
IMHO if someone's .emacs wants to chat during startup, then he needs to
fix his  .emacs if he wants to use --daemon.  
Chatty deamons are evil (or devils?). :-)

  > 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).

Looking at it again, it should not be too bad, tedious, but not complicated.

  > 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.

Depending on what the definition if "right" is... If it means enabling
interaction before detaching, then you might be right (haven't checked).
If it means the patch that Romain posted, that should be fine to go in
now.

  > What happens to messages resulting from executing .emacs in solution nb
  > 2 are they sent to stdout or are they silently dropped?

deamon's stdin/stdout/stderr go to /dev/null.

  > 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.

How about "emacs -Q --daemon" ?  Is this CVS HEAD, or your famous patched tree?

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Trent W. Buck]

On Thu, Oct 02, 2008 at 05:32:32PM -0400, Stefan Monnier wrote:
> >> 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).

What happens if .emacs asks questions?  Does 'emacs --daemon' require
a terminal?

Also, I'm currently using the following test to check whether the
running Emacs supports --daemon.  If you break it, please make some
other test work.

    emacs --batch -q --no-site-file --daemon &>/dev/null

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Trent W. Buck]

On Thu, Oct 02, 2008 at 03:34:42PM -0700, Dan Nicolaescu wrote:
> Depending on what the definition if "right" is... If it means enabling
> interaction before detaching, then you might be right (haven't checked).
> If it means the patch that Romain posted, that should be fine to go in
> now.

Currently if you "emacs --daemon" and .emacs contains a syntax error,
you don't get any warning of this.

Currently if you do something like "emacs --daemon -f irc -f gnus",
any minibuffer prompts will appear when you connect a client.

I think I'd prefer the first to change and the latter to stay the
same, but I haven't had any coffee yet.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Stefan Monnier]

> Is that desirable?  We seem to be looking at this from different points
> of view.  I want the daemon to start the server early, and that should
> be the only way to interact with it.  You want to have a full blown
> emacs until the server is started...

I think we agree: I also want a full blown Emacs until the server is
started.  But I also want to run some Elisp code (especially the .emacs)
before the server is started.

> IMHO if someone's .emacs wants to chat during startup, then he needs to
> fix his  .emacs if he wants to use --daemon.

Agreed.

> Chatty deamons are evil (or devils?). :-)

But daemons which fork before detecting if there's an error somewhere
and hence don't report such errors are even more evil.

>> 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).
> Looking at it again, it should not be too bad, tedious, but not complicated.

Could be.

> Depending on what the definition if "right" is... If it means enabling
> interaction before detaching, then you might be right (haven't checked).
> If it means the patch that Romain posted, that should be fine to go in
> now.

I can't tell yet whether Romain's patch does the right thing: do errors
in .emacs get properly reported to stdout?

>> What happens to messages resulting from executing .emacs in solution nb
>> 2 are they sent to stdout or are they silently dropped?
> deamon's stdin/stdout/stderr go to /dev/null.

That's mostly OK, but not before the .emacs (and --eval) get processed.

>> 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.

> How about "emacs -Q --daemon" ?

Same thing.

> Is this CVS HEAD, or your famous patched tree?

;-)  CVS HEAD.


        Stefan

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

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

  > > Depending on what the definition if "right" is... If it means enabling
  > > interaction before detaching, then you might be right (haven't checked).
  > > If it means the patch that Romain posted, that should be fine to go in
  > > now.
  > 
  > I can't tell yet whether Romain's patch does the right thing: do errors
  > in .emacs get properly reported to stdout?

Romain's patch solves the other problem: the fact that the initial
parent process returns before the server is started, so that 
emacs --daemon && emacsclient -c 
does not work.

I am not sure if moving the code that forks/disconnects from the
terminal later solves the reporting errors problem.  (and I can't really
try at the moment).

  > >> What happens to messages resulting from executing .emacs in solution nb
  > >> 2 are they sent to stdout or are they silently dropped?
  > > deamon's stdin/stdout/stderr go to /dev/null.
  > 
  > That's mostly OK, but not before the .emacs (and --eval) get processed.
  > 
  > >> 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.
  > 
  > > How about "emacs -Q --daemon" ?
  > 
  > Same thing.

Hmm, you mean that after "emacs -Q --daemon" if you look with ps there's
no emacs process at all?  And "emacsclient -t" does not connect to it?

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Stefan Monnier]

> Hmm, you mean that after "emacs -Q --daemon" if you look with ps there's
> no emacs process at all?  And "emacsclient -t" does not connect to it?

Exactly.  But I haven't investigated further yet.  Most likely it's
a simple error somewhere that causes Emacs to exit but the message is
throw away.  That's exactly for these kinds of reasons that it's
important to keep sending messages to stdout at least until after the
server is started: otherwise debugging is a pain.


        Stefan

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

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

  > > Hmm, you mean that after "emacs -Q --daemon" if you look with ps there's
  > > no emacs process at all?  And "emacsclient -t" does not connect to it?
  > 
  > Exactly.  But I haven't investigated further yet.  Most likely it's
  > a simple error somewhere that causes Emacs to exit but the message is
  > throw away.  

If this is with an up to date pristine tree, then please debug it, it's
very bad.  I have not seen anything like this on any of the systems that
I use.

  > That's exactly for these kinds of reasons that it's important to
  > keep sending messages to stdout at least until after the server is
  > started: otherwise debugging is a pain.

Well, but that is not how things work when using emacs normally
(i.e. interactive session without --daemon).  
  - Errors in .emacs are shown in the *Messages* buffer.  That still happens
  with --daemon.
  - Interactive questions (like a y-or-n-p in .emacs) get asked in the
  first emacs frame that appears.  I think we agree that something like
  this is ill formed for --daemon.  It would be nice if it failed more
  graciously, but I am not sure it can be easily done within the current
  constraints.


BTW, the splash screen covers that *Messages* buffer quite fast, so
errors at startup are not displayed for too long ...

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Here's version one of a patch for this, please let me know what you
  > think.

Here's a version based on your code that also moves detaching from the
terminal later.  emacs --daemon && emacsclient -c works.
Errors in ~/.emacs show up in the *Messages* buffer (as they do when
starting up normally). 
Only lightly tested.  Looking at the patch again, I there aren't any new
features here, so it can go in as a bug fix.

Index: lisp/startup.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v
retrieving revision 1.508
diff -u -3 -p -r1.508 startup.el
--- lisp/startup.el	6 Oct 2008 16:16:30 -0000	1.508
+++ lisp/startup.el	6 Oct 2008 20:18:41 -0000
@@ -1219,7 +1219,7 @@ opening the first frame (e.g. open a con
   ;; processing all command line arguments to allow e.g. `server-name'
   ;; to be changed before the server starts.
   (when (daemonp)
-    (server-start))
+    (daemon-detach-and-start-server))
 
   ;; Run emacs-session-restore (session management) if started by
   ;; the session manager and we have a session manager connection.
Index: src/emacs.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/emacs.c,v
retrieving revision 1.448
diff -u -3 -p -r1.448 emacs.c
--- src/emacs.c	6 Oct 2008 16:16:56 -0000	1.448
+++ src/emacs.c	6 Oct 2008 20:18:41 -0000
@@ -238,6 +238,10 @@ int noninteractive1;
 /* Nonzero means Emacs was started as a daemon.  */
 int is_daemon = 0;
 
+/* Pipe used to send exit notification to the daemon parent at
+   startup.  */
+static int daemon_pipe[2];
+
 /* Save argv and argc.  */
 char **initial_argv;
 int initial_argc;
@@ -1078,25 +1082,7 @@ main (int argc, char **argv)
   if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args))
     {
 #ifndef DOS_NT
-      pid_t f = fork ();
-      int nfd;
-      if (f > 0)
-	exit (0);
-      if (f < 0)
-	{
-	  fprintf (stderr, "Cannot fork!\n");
-	  exit (1);
-	}
-
-      nfd = open ("/dev/null", O_RDWR);
-      dup2 (nfd, 0);
-      dup2 (nfd, 1);
-      dup2 (nfd, 2);
-      close (nfd);
       is_daemon = 1;
-#ifdef HAVE_SETSID
-      setsid();
-#endif
 #else /* DOS_NT */
       fprintf (stderr, "This platform does not support the -daemon flag.\n");
       exit (1);
@@ -2393,6 +2379,87 @@ DEFUN ("daemonp", Fdaemonp, Sdaemonp, 0,
   return is_daemon ? Qt : Qnil;
 }
 
+
+DEFUN ("daemon-detach-and-start-server", Fdaemon_detach_and_start_server, Sdaemon_detach_and_start_server, 0, 0, 0,
+       doc: /* Detach from terminal and start the server */)
+  ()
+{
+  static char daemon_initialized = 0;
+  pid_t f;
+  int nfd;
+
+  if (!is_daemon)
+    error ("This function can only be called if emacs is run as a daemon");
+
+  if (daemon_initialized)
+    error ("The daemon has already been initialized");
+
+  if (NILP (Vafter_init_time))
+    error ("This function can only be called after loading the init files");
+  
+  /* Start as a daemon: fork a new child process which will run the
+     rest of the initialization code, then exit.
+
+     We want to avoid exiting before the server socket is ready, so
+     use a pipe for synchronization.  The parent waits for the child
+     to close its end of the pipe (using `daemon-initialized')
+     before exiting.  */
+  if (pipe (daemon_pipe) == -1)
+    {
+      fprintf (stderr, "Cannot pipe!\n");
+      exit (1);
+    }
+
+  f = fork ();
+  if (f > 0)
+    {
+      int retval;
+      char buf[1];
+
+      /* Close unused writing end of the pipe.  */
+      close (daemon_pipe[1]);
+
+      /* Just wait for the child to close its end of the pipe.  */
+      do
+	{
+	  retval = read (daemon_pipe[0], &buf, 1);
+	}
+      while (retval == -1 && errno == EINTR);
+
+      if (retval < 0)
+	{
+	  fprintf (stderr, "Error reading status from child\n");
+	  exit (1);
+	}
+
+      close (daemon_pipe[0]);
+      exit (0);
+    }
+  if (f < 0)
+    {
+      fprintf (stderr, "Cannot fork!\n");
+      exit (1);
+    }
+
+  /* Close unused reading end of the pipe.  */
+  close (daemon_pipe[0]);
+
+  nfd = open ("/dev/null", O_RDWR);
+  dup2 (nfd, 0);
+  dup2 (nfd, 1);
+  dup2 (nfd, 2);
+  close (nfd);
+  is_daemon = 1;
+#ifdef HAVE_SETSID
+  setsid();
+#endif
+  call0 (intern ("server-start"));
+
+  /* Closing the pipe will notify the parent that it can exit. */
+  close (daemon_pipe[1]);
+  daemon_initialized = 1;
+}
+
 void
 syms_of_emacs ()
 {
@@ -2412,6 +2479,7 @@ syms_of_emacs ()
   defsubr (&Sinvocation_name);
   defsubr (&Sinvocation_directory);
   defsubr (&Sdaemonp);
+  defsubr (&Sdaemon_detach_and_start_server);
 
   DEFVAR_LISP ("command-line-args", &Vcommand_line_args,
 	       doc: /* Args passed by shell to Emacs, as a list of strings.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Stefan Monnier]

> Errors in ~/.emacs show up in the *Messages* buffer (as they do when
> starting up normally). 

But is the *Messages* buffer automatically displayed (as is done when
starting up normally)?  This is the main reason why I think that .emacs
messages should go to stdout.  Especially since the error might even be
something that breaks the server, so you can't connect later on to take
a look at the *Messages* buffer.


        Stefan

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > > Errors in ~/.emacs show up in the *Messages* buffer (as they do when
  > > starting up normally). 

There are multiple issues being discussed here.

1. 
  > But is the *Messages* buffer automatically displayed (as is done when
  > starting up normally)?  

Not yet, but it just takes one extra `if' to do it:

--- server.el.~1.168.~     2008-09-24 17:34:59.000000000 -0700
+++ server.el              2008-10-07 08:09:16.000000000 -0700
@@ -606,7 +606,9 @@ Server mode runs a process that accepts 
     (process-put proc 'terminal (frame-terminal frame))
 
     ;; Display *scratch* by default.
-    (switch-to-buffer (get-buffer-create "*scratch*") 'norecord)
+    (switch-to-buffer
+     (get-buffer-create 
+      (if init-file-had-error "*Messages*" "*scratch*")) 'norecord)
 
     ;; Reply with our pid.
     (server-send-string proc (concat "-emacs-pid "

2. During the normal interactive startup the splash screen nowadays
covers the *Messages* buffer too fast, so the user can miss the error.
I should file a bug about this...

  >  This is the main reason why I think that .emacs messages should go
  > to stdout.

3. There's no code in emacs now that can do that for interactive
sessions, and when I looked at this it did not look that it can be a
small change acceptable during the feature freeze.  The `noninteractive'
code has it's claws in too many places.

  > Especially since the error might even be something that breaks the
  > server, so you can't connect later on to take a look at the
  > *Messages* buffer.

5. Making the output go to stdout does not avoid this problem at all, it
reduces the possibility somewhat, but it does not avoid it.

6. But my original code to start the server early minimizes the window
of opportunity for problems in starting the server, the more .emacs,
default.el, site-start.el code you run, the more potential for problems
in starting the server later.  Yes, starting the server early was
entirely intentional.

7. This bug report is about something else: 
emacs --daemon && emacsclient -c 
not working.  Romain's patch looks good, it does not add features, it's
just a bug fix, so I don't see any reason it cannot go in right now.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Romain Francoise]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Here's a version based on your code that also moves detaching from the
> terminal later.

Hmm, but the initial frame doesn't get created anyway because
`is_daemon' is still set early like before, so it doesn't really
change much.  I'm unsure which problems this patch addresses.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Here's a version based on your code that also moves detaching from the
  > > terminal later.
  > 
  > Hmm, but the initial frame doesn't get created anyway because

Not sure why you mention that.

  > `is_daemon' is still set early like before, so it doesn't really
  > change much.  I'm unsure which problems this patch addresses.

It moves detaching from the terminal to later, so if emacs ever gets to
use stdout/stdin durin startup, it will just work (hopefully).

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Trent W. Buck]

On Tue, Oct 07, 2008 at 08:31:47AM -0700, Dan Nicolaescu wrote:
>> But is the *Messages* buffer automatically displayed (as is done when
>> starting up normally)?
>
> Not yet, but it just takes one extra `if' to do it:
>
> --- server.el.~1.168.~     2008-09-24 17:34:59.000000000 -0700
> +++ server.el              2008-10-07 08:09:16.000000000 -0700
> @@ -606,7 +606,9 @@ Server mode runs a process that accepts
>      (process-put proc 'terminal (frame-terminal frame))
>
>      ;; Display *scratch* by default.
> -    (switch-to-buffer (get-buffer-create "*scratch*") 'norecord)
> +    (switch-to-buffer
> +     (get-buffer-create
> +      (if init-file-had-error "*Messages*" "*scratch*")) 'norecord)
>
>      ;; Reply with our pid.
>      (server-send-string proc (concat "-emacs-pid "

Will this result in *Messages* being shown in all emacsclients, or
only the first one?

> 2. During the normal interactive startup the splash screen nowadays
> covers the *Messages* buffer too fast, so the user can miss the error.
> I should file a bug about this...
>
>>  This is the main reason why I think that .emacs messages should go
>> to stdout.

Wouldn't it be better to address the actual issue (splash screen hides
*Messages* when something went wrong) rather than side effects
(*Messages* is hidden when --daemon, too)?

> 7. This bug report is about something else: emacs --daemon &&
> emacsclient -c not working.  Romain's patch looks good, it does not
> add features, it's just a bug fix, so I don't see any reason it
> cannot go in right now.

Correct; stdout / splash screen stuff should be forked to a separate
bug.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Stefan Monnier]

>> 2. During the normal interactive startup the splash screen nowadays
>> covers the *Messages* buffer too fast, so the user can miss the error.
>> I should file a bug about this...
>> 
>>> This is the main reason why I think that .emacs messages should go
>>> to stdout.

> Wouldn't it be better to address the actual issue (splash screen hides
> *Messages* when something went wrong) rather than side effects
> (*Messages* is hidden when --daemon, too)?

The splash screen issue is completely separate.

>> 7. This bug report is about something else: emacs --daemon &&
>> emacsclient -c not working.  Romain's patch looks good, it does not
>> add features, it's just a bug fix, so I don't see any reason it
>> cannot go in right now.

> Correct; stdout / splash screen stuff should be forked to a separate bug.

Yes and no: the right fix for one is also the right fix for the
other, AFAICT.


        Stefan

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Stefan Monnier]

> 1. 
>> But is the *Messages* buffer automatically displayed (as is done when
>> starting up normally)?
> Not yet, but it just takes one extra `if' to do it:

Actually, I don't care much that issue right now.  I'd rather remove the
issue altogether than try and fix it.

>> This is the main reason why I think that .emacs messages should go
>> to stdout.

> 3. There's no code in emacs now that can do that for interactive
> sessions, and when I looked at this it did not look that it can be a
> small change acceptable during the feature freeze.  The `noninteractive'
> code has it's claws in too many places.

I'm not sure it's the case: my Emacs does send the .emacs's messages to
stdout before opening the initial X11 frame and I can't remember having
to make many significant changes for that, mostly I introduced a new var
`uninitialized' (set to nil before loading .emacs and to t afterwards)
and then changed a bunch of places that check `noninteractive' to check
`noninteractive || uninintialized'.

>> Especially since the error might even be something that breaks the
>> server, so you can't connect later on to take a look at the
>> *Messages* buffer.

> 5. Making the output go to stdout does not avoid this problem at all, it
> reduces the possibility somewhat, but it does not avoid it.

To the contrary, it eliminates the problem altogether: no need to access
the *Messages* buffer since you already get the relevant info straight
from stdout.

> 6. But my original code to start the server early minimizes the window
> of opportunity for problems in starting the server, the more .emacs,
> default.el, site-start.el code you run, the more potential for problems
> in starting the server later.  Yes, starting the server early was
> entirely intentional.

I see what you mean.  It might indeed make things simpler, but it
eliminates a lot of flexibility.

> 7. This bug report is about something else: 
> emacs --daemon && emacsclient -c
> not working.  Romain's patch looks good, it does not add features, it's
> just a bug fix, so I don't see any reason it cannot go in right now.

Looking at your patch again, I think it's indeed going in the
right direction.  A few notes/questions, tho:

I'd rather have just a `daemon-detach' and then be able to call
server-start separately from startup.el.  Maybe a way to get that is to
leave the fork in emacs.c and to turn daemon-detach into little more
than close (daemon_pipe[1]).  WDYT?


        Stefan

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

Here's a patch that adds support for --daemon=SERVER_NAME
Using --daemon=SERVER_NAME for scripts is much nicer than: 
--daemon --eval '(setq server-name "SERVER_NAME")' 
So IMVHO something like this could go in now...


Index: lisp/server.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/server.el,v
retrieving revision 1.168
diff -u -3 -p -r1.168 server.el
--- lisp/server.el	24 Sep 2008 20:12:02 -0000	1.168
+++ lisp/server.el	13 Oct 2008 00:15:28 -0000
@@ -446,7 +446,7 @@ Creates the directory if necessary and m
       (error "The directory %s is unsafe" dir))))
 
 ;;;###autoload
-(defun server-start (&optional leave-dead)
+(defun server-start (&optional leave-dead server-arg)
   "Allow this Emacs process to be a server for client processes.
 This starts a server communications subprocess through which
 client \"editors\" can send your editing commands to this Emacs
@@ -463,6 +463,8 @@ kill any existing server communications 
     (when server-process
       ;; kill it dead!
       (ignore-errors (delete-process server-process)))
+    (when (stringp server-arg)
+      (setq server-name server-arg))
     ;; Delete the socket files made by previous server invocations.
     (condition-case ()
 	(delete-file (expand-file-name server-name server-socket-dir))
Index: lisp/startup.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v
retrieving revision 1.513
diff -u -3 -p -r1.513 startup.el
--- lisp/startup.el	12 Oct 2008 16:59:01 -0000	1.513
+++ lisp/startup.el	13 Oct 2008 00:15:28 -0000
@@ -1212,8 +1212,8 @@ the `--debug-init' option to view a comp
   ;; This is done after loading the user's init file and after
   ;; processing all command line arguments to allow e.g. `server-name'
   ;; to be changed before the server starts.
-  (when (daemonp)
-    (server-start))
+  (let ((dn (daemonp)))
+    (when dn (server-start nil dn)))
 
   ;; Run emacs-session-restore (session management) if started by
   ;; the session manager and we have a session manager connection.
Index: src/emacs.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/emacs.c,v
retrieving revision 1.448
diff -u -3 -p -r1.448 emacs.c
--- src/emacs.c	6 Oct 2008 16:16:56 -0000	1.448
+++ src/emacs.c	13 Oct 2008 00:15:28 -0000
@@ -237,6 +237,8 @@ int noninteractive1;
 
 /* Nonzero means Emacs was started as a daemon.  */
 int is_daemon = 0;
+/* Name for the server started by the daemon.*/
+static char *daemon_name;
 
 /* Save argv and argc.  */
 char **initial_argv;
@@ -792,6 +794,7 @@ main (int argc, char **argv)
 #endif
   int no_loadup = 0;
   char *junk = 0;
+  char *dname_arg = 0;
 
 #if GC_MARK_STACK
   extern Lisp_Object *stack_base;
@@ -1074,8 +1077,8 @@ main (int argc, char **argv)
       printf (USAGE4, bug_reporting_address ());
       exit (0);
     }
-
-  if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args))
+  if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args)
+      || argmatch (argv, argc, "-daemon", "--daemon", 5, &dname_arg, &skip_args))
     {
 #ifndef DOS_NT
       pid_t f = fork ();
@@ -1088,6 +1091,8 @@ main (int argc, char **argv)
 	  exit (1);
 	}
 
+      if (dname_arg)
+      	daemon_name = xstrdup (dname_arg);
       nfd = open ("/dev/null", O_RDWR);
       dup2 (nfd, 0);
       dup2 (nfd, 1);
@@ -2387,10 +2392,17 @@ decode_env_path (evarname, defalt)
 }
 
 DEFUN ("daemonp", Fdaemonp, Sdaemonp, 0, 0, 0,
-       doc: /* Return t if the current emacs process is a daemon.  */)
+       doc: /* Return non-nil if the current emacs process is a daemon.
+If the daemon was give a name argument, return that name. */)
   ()
 {
-  return is_daemon ? Qt : Qnil;
+  if (is_daemon)
+    if (daemon_name)
+      return build_string (daemon_name);
+    else
+      return Qt;
+  else
+    return Qnil;
 }
 
 void

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Stefan Monnier]

> -(defun server-start (&optional leave-dead)
> +(defun server-start (&optional leave-dead server-arg)
>    "Allow this Emacs process to be a server for client processes.
>  This starts a server communications subprocess through which
>  client \"editors\" can send your editing commands to this Emacs
> @@ -463,6 +463,8 @@ kill any existing server communications 
>      (when server-process
>        ;; kill it dead!
>        (ignore-errors (delete-process server-process)))
> +    (when (stringp server-arg)
> +      (setq server-name server-arg))

Changing the global var like this is an ugly hack.
I'd rather not add any feature in this direction for now anyway.


        Stefan

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

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

  > > -(defun server-start (&optional leave-dead)
  > > +(defun server-start (&optional leave-dead server-arg)
  > >    "Allow this Emacs process to be a server for client processes.
  > >  This starts a server communications subprocess through which
  > >  client \"editors\" can send your editing commands to this Emacs
  > > @@ -463,6 +463,8 @@ kill any existing server communications 
  > >      (when server-process
  > >        ;; kill it dead!
  > >        (ignore-errors (delete-process server-process)))
  > > +    (when (stringp server-arg)
  > > +      (setq server-name server-arg))
  > 
  > Changing the global var like this is an ugly hack.

Sure, it can be moved before the call to `sever-start'
I also wanted to make that variable obsolete and make the functional
interface the preferred method.
But that is a separate issue, and it's quite orthogonal to the point of
this patch.

  > I'd rather not add any feature in this direction for now anyway.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Stefan Monnier]

>> > -(defun server-start (&optional leave-dead)
>> > +(defun server-start (&optional leave-dead server-arg)
>> >    "Allow this Emacs process to be a server for client processes.
>> >  This starts a server communications subprocess through which
>> >  client \"editors\" can send your editing commands to this Emacs
>> > @@ -463,6 +463,8 @@ kill any existing server communications 
>> >      (when server-process
>> >        ;; kill it dead!
>> >        (ignore-errors (delete-process server-process)))
>> > +    (when (stringp server-arg)
>> > +      (setq server-name server-arg))
>> 
>> Changing the global var like this is an ugly hack.

> Sure, it can be moved before the call to `sever-start'
> I also wanted to make that variable obsolete and make the functional
> interface the preferred method.

There's no need or reason to make it obsolete.  You basically want to
replace the last two lines above with

    (unless (stringp server-arg)
      (setq server-arg server-name))

and then pass server-arg where it's needed.

> But that is a separate issue, and it's quite orthogonal to the point of
> this patch.

Since I'm basically not excited at the idea of adding yet more features
at this point, it's good to try and make sure that any such proposal
comes with the cleanest code possible, rather than with a quick fix.


        Stefan

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

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

  > >> > -(defun server-start (&optional leave-dead)
  > >> > +(defun server-start (&optional leave-dead server-arg)
  > >> >    "Allow this Emacs process to be a server for client processes.
  > >> >  This starts a server communications subprocess through which
  > >> >  client \"editors\" can send your editing commands to this Emacs
  > >> > @@ -463,6 +463,8 @@ kill any existing server communications 
  > >> >      (when server-process
  > >> >        ;; kill it dead!
  > >> >        (ignore-errors (delete-process server-process)))
  > >> > +    (when (stringp server-arg)
  > >> > +      (setq server-name server-arg))
  > >> 
  > >> Changing the global var like this is an ugly hack.
  > 
  > > Sure, it can be moved before the call to `sever-start'
  > > I also wanted to make that variable obsolete and make the functional
  > > interface the preferred method.
  > 
  > There's no need or reason to make it obsolete.  You basically want to
  > replace the last two lines above with
  > 
  >     (unless (stringp server-arg)
  >       (setq server-arg server-name))
  > 
  > and then pass server-arg where it's needed.

Ah, OK.  I had the impression that server-name was needed for other
functions to work correctly, but that is not the case.
Updated patch follows.

Now it's your choice if you want this patch now or later.  I'll update
the docs when checking it in.

Index: lisp/server.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/server.el,v
retrieving revision 1.168
diff -u -3 -p -r1.168 server.el
--- lisp/server.el	24 Sep 2008 20:12:02 -0000	1.168
+++ lisp/server.el	14 Oct 2008 07:16:41 -0000
@@ -446,7 +446,7 @@ Creates the directory if necessary and m
       (error "The directory %s is unsafe" dir))))
 
 ;;;###autoload
-(defun server-start (&optional leave-dead)
+(defun server-start (&optional leave-dead server-arg)
   "Allow this Emacs process to be a server for client processes.
 This starts a server communications subprocess through which
 client \"editors\" can send your editing commands to this Emacs
@@ -463,9 +463,11 @@ kill any existing server communications 
     (when server-process
       ;; kill it dead!
       (ignore-errors (delete-process server-process)))
+    (unless (stringp server-arg)
+      (setq server-arg server-name))
     ;; Delete the socket files made by previous server invocations.
     (condition-case ()
-	(delete-file (expand-file-name server-name server-socket-dir))
+	(delete-file (expand-file-name server-arg server-socket-dir))
       (error nil))
     ;; If this Emacs already had a server, clear out associated status.
     (while server-clients
@@ -476,7 +478,7 @@ kill any existing server communications 
 	  (server-log (message "Server stopped"))
 	  (setq server-process nil))
       (let* ((server-dir (if server-use-tcp server-auth-dir server-socket-dir))
-	     (server-file (expand-file-name server-name server-dir)))
+	     (server-file (expand-file-name server-arg server-dir)))
 	;; Make sure there is a safe directory in which to place the socket.
 	(server-ensure-safe-dir server-dir)
 	;; Remove any leftover socket or authentication file.
@@ -491,7 +493,7 @@ kill any existing server communications 
 	  (add-hook 'kill-emacs-hook (lambda () (server-mode -1))) ;Cleanup upon exit.
 	  (setq server-process
 		(apply #'make-network-process
-		       :name server-name
+		       :name server-arg
 		       :server t
 		       :noquery t
 		       :sentinel 'server-sentinel
Index: lisp/startup.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/startup.el,v
retrieving revision 1.513
diff -u -3 -p -r1.513 startup.el
--- lisp/startup.el	12 Oct 2008 16:59:01 -0000	1.513
+++ lisp/startup.el	14 Oct 2008 07:16:41 -0000
@@ -1212,8 +1212,8 @@ the `--debug-init' option to view a comp
   ;; This is done after loading the user's init file and after
   ;; processing all command line arguments to allow e.g. `server-name'
   ;; to be changed before the server starts.
-  (when (daemonp)
-    (server-start))
+  (let ((dn (daemonp)))
+    (when dn (server-start nil dn)))
 
   ;; Run emacs-session-restore (session management) if started by
   ;; the session manager and we have a session manager connection.
Index: src/emacs.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/emacs.c,v
retrieving revision 1.448
diff -u -3 -p -r1.448 emacs.c
--- src/emacs.c	6 Oct 2008 16:16:56 -0000	1.448
+++ src/emacs.c	14 Oct 2008 07:16:41 -0000
@@ -237,6 +237,8 @@ int noninteractive1;
 
 /* Nonzero means Emacs was started as a daemon.  */
 int is_daemon = 0;
+/* Name for the server started by the daemon.*/
+static char *daemon_name;
 
 /* Save argv and argc.  */
 char **initial_argv;
@@ -792,6 +794,7 @@ main (int argc, char **argv)
 #endif
   int no_loadup = 0;
   char *junk = 0;
+  char *dname_arg = 0;
 
 #if GC_MARK_STACK
   extern Lisp_Object *stack_base;
@@ -1074,8 +1077,8 @@ main (int argc, char **argv)
       printf (USAGE4, bug_reporting_address ());
       exit (0);
     }
-
-  if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args))
+  if (argmatch (argv, argc, "-daemon", "--daemon", 5, NULL, &skip_args)
+      || argmatch (argv, argc, "-daemon", "--daemon", 5, &dname_arg, &skip_args))
     {
 #ifndef DOS_NT
       pid_t f = fork ();
@@ -1088,6 +1091,8 @@ main (int argc, char **argv)
 	  exit (1);
 	}
 
+      if (dname_arg)
+      	daemon_name = xstrdup (dname_arg);
       nfd = open ("/dev/null", O_RDWR);
       dup2 (nfd, 0);
       dup2 (nfd, 1);
@@ -2387,10 +2392,17 @@ decode_env_path (evarname, defalt)
 }
 
 DEFUN ("daemonp", Fdaemonp, Sdaemonp, 0, 0, 0,
-       doc: /* Return t if the current emacs process is a daemon.  */)
+       doc: /* Return non-nil if the current emacs process is a daemon.
+If the daemon was give a name argument, return that name. */)
   ()
 {
-  return is_daemon ? Qt : Qnil;
+  if (is_daemon)
+    if (daemon_name)
+      return build_string (daemon_name);
+    else
+      return Qt;
+  else
+    return Qnil;
 }
 
 void

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Here's version one of a patch for this, please let me know what you
  > think.

I checked this in with some changes requested by Stefan.

bug#1058: 23.0.60; emacs --daemon should not return until socket is ready

[Dan Nicolaescu]

Dan Nicolaescu <dann@ics.uci.edu> writes:

  > Stefan Monnier <monnier@iro.umontreal.ca> writes:
  > 
  >   > >> > -(defun server-start (&optional leave-dead)
  >   > >> > +(defun server-start (&optional leave-dead server-arg)
  >   > >> >    "Allow this Emacs process to be a server for client processes.
  >   > >> >  This starts a server communications subprocess through which
  >   > >> >  client \"editors\" can send your editing commands to this Emacs
  >   > >> > @@ -463,6 +463,8 @@ kill any existing server communications 
  >   > >> >      (when server-process
  >   > >> >        ;; kill it dead!
  >   > >> >        (ignore-errors (delete-process server-process)))
  >   > >> > +    (when (stringp server-arg)
  >   > >> > +      (setq server-name server-arg))
  >   > >> 
  >   > >> Changing the global var like this is an ugly hack.
  >   > 
  >   > > Sure, it can be moved before the call to `sever-start'
  >   > > I also wanted to make that variable obsolete and make the functional
  >   > > interface the preferred method.
  >   > 
  >   > There's no need or reason to make it obsolete.  You basically want to
  >   > replace the last two lines above with
  >   > 
  >   >     (unless (stringp server-arg)
  >   >       (setq server-arg server-name))
  >   > 
  >   > and then pass server-arg where it's needed.
  > 
  > Ah, OK.  I had the impression that server-name was needed for other
  > functions to work correctly, but that is not the case.
  > Updated patch follows.
  > 
  > Now it's your choice if you want this patch now or later.  I'll update
  > the docs when checking it in.

I checked in a version of this changed as requested by Stefan.