On Wednesday, July 09, 2014 09:23:10 Peder O. Klingenberg wrote:
> On Tue, Jul 08 2014 at 09:30, Alexis wrote:
> > Summary of steps to reproduce:
> > 
> > 1. emacs -q --daemon
> > 2. emacsclient -c
> > 3. C-x C-c
> > 4. The `emacs --daemon` process is no longer running.
> 
> The symptoms seem similar to something I saw a couple of months back.
> Reported as bug #17125.  That apparently had something to do with my
> fonts.
> 
> Try attaching gdb to the emacs process before starting the emacsclient,
> and see if you catch a signal as you exit emacsclient?
> 
> I haven't had time to pursue that bug any further.  Dmitry Antipov
> provided a patch that worked for me, but apparently had some
> deficiencies.
> 
> ...Peder...

I can't speak to resolve the issue proper, but I have run into many issues 
with emacs in --daemon mode dissappearing when trying to open a X frame as
seems to be occuring here.

I resolved them permanently by taking all the stuff that was X specific in the
init such as font and color and ran the .el file off a before-make-frame hook.

I set a simple binary sentinal to make sure that it only ran once.

Never had a problem since. In my thoughts if --daemon has not gathered any 
information on the X environment which makes sense then deferring execution
of configuring X stuff seems to be the only way out for now.

Here is the relevant part of my config in gitweb. Ignore my grail decorations,
the control block is quite simple and explanatory.

http://lispblivet.sx/git/?p=emacs.git;a=blob;f=emacs/grail.el;h=85e7adb6495d04a50ab6d1cd0661cd7c93e572af;hb=HEAD#l320

It might be useful in that if the workaround succeeds for the initial poster
it could narrow down the specific bits of information that emacs lacks
in --daemon mode.

How to solve it correctly is a bit beyond me, I just have a work-around to
what I think is the problem.

Mike Mattie