bug#1107: #1107 - 23.0.60; Emacs --daemon crashes when emacsclient tries to establish a connection on OS X - Emacs bug report logs

[Dan Nicolaescu]

Adrian Robert <adrian.b.robert@gmail.com> writes:

  > OK, it seems that the NS GUI stuff cannot be used in a child process
  > from fork():
  > 
  > http://developer.apple.com/ReleaseNotes/CoreFoundation/CoreFoundation.html
  > 
  > (search for "fork"):
  > 
  > > Due to the behavior of fork(), CoreFoundation cannot be used on the
  > > child-side of fork(). If you fork(), you must follow that with an
  > > exec*() call of some sort, and you should not use CoreFoundation
  > > APIs within the child, before the exec*().

Bleah, how ugly.  Do you know if this is also a problem if you never use
CoreFoundation (whatever that is) before the fork() call?

  > I put in a really ugly hack that calls execve() in the child after the
  > fork (which then means the daemonization has to be short-circuited the
  > second time), and this works in all respects except:
  > 
  > The emacsclient must be given "--socket-name /tmp/emacs503/server" to
  > find the server.  Else it gives "No socket or alternate editor."
  > 
  > On the other hand, if I start emacs -Q and run 'server-start', this
  > argument is NOT needed, and furthermore if it IS given it, it fails
  > with "connect: Connection refused".
  > 
  > Any insight into what is happening here?

What is (daemonp) returning?  When using --daemon, if the value returned by
(daemonp) is a string is used to set `server-name', before calling
`server-start'. 

So does emacs -Q -f server-start  work now? (You reported problems in a
previous message...)