GNU bug report logs - #9674
24.0.90; Closing an emacsclient frame always kills daemon

Previous Next

To reply to this bug, email your comments to 9674 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Damien Cassou <damien.cassou <at> gmail.com>
To: emacs-devel <at> gnu.org, bug-gnu-emacs <at> gnu.org
Subject: 24.0.90; Closing an emacsclient frame always kills daemon
Date: Wed, 5 Oct 2011 14:24:53 +0200

Hi,

I open emacs with the following:

emacsclient --alternate-editor="" -c ~/.bashrc

According to the manual, it creates a daemon if none is running and
then creates a client by connecting to this daemon. I confirm this
behavior by looking at the running processes: I have one process for
emacsclient and one for emacs --daemon. However, as soon as I close
the last running emacsclient (with C-x C-c or C-x #), the daemon is
also terminated. Some more information:

- Running with gdb prints a "Program existed normally".

- I can reproduce on sources downloaded from bzr, on debian unstable
(http://emacs.naquadah.org/unstable/) and ubuntu natty
(https://launchpad.net/~cassou/+archive/emacs). The directives used
for compilation are shown below. (note that I used -O0 and
--with-x-toolkit=gtk3).

- Launching emacsclient with -nw does *not* exhibit the problem.

- Compiling with --with-x-toolkit=gtk does exhibit the same problem.

- I also compiled with --with-x-toolkit=lucid, but I must have made
something wrong as I also got the "Warning: due to a long standing
Gtk+ bug..." error message when I started emacs.

- I was not able to run emacs with -q option as emacsclient does not
accept it nor does it allow to pass it to the daemon to be created. I,
however, renamed my .emacs.d directory so that it didn't get loaded (
I have no ~/.emacs file)


Here are the compilation instructions I used with the sources from
bzr. They are very exactly the same as the one used by Julien Danjou
to create http://emacs.naquadah.org/unstable except for the -O0 that I
used to see if the problem persisted (and it does).

CFLAGS="-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O0" ./configure
--build i686-linux-gnu --host i686-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/24.0.90/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.0.90/site-lisp:/usr/share/emacs/site-lisp
--without-compress-info --with-crt-dir=/usr/lib/i386-linux-gnu/
--with-x=yes --with-x-toolkit=gtk3 --with-imagemagick=yes

/usr/bin/make -j8 CFLAGS="-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g
-O0" LDFLAGS="-g -Wl,--as-needed"

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  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_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Load-path shadows:
/usr/share/emacs/24.0.90/site-lisp/cmake-data/cmake-mode hides
/usr/share/emacs/site-lisp/cmake-mode
/usr/share/emacs/24.0.90/site-lisp/debian-startup hides
/usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/site-lisp/rst hides /usr/share/emacs/24.0.90/lisp/textmodes/rst

Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug help-mode easymenu view vc-git regexp-opt sh-script executable
server time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)


-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

Message #8 received at 9674 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Damien Cassou <damien.cassou <at> gmail.com>
Cc: 9674 <at> debbugs.gnu.org
Subject: Re: bug#9674: 24.0.90;
	Closing an emacsclient frame always kills daemon
Date: Wed, 05 Oct 2011 13:54:48 -0400

Damien Cassou wrote:

> - I also compiled with --with-x-toolkit=lucid, but I must have made
> something wrong as I also got the "Warning: due to a long standing
> Gtk+ bug..." error message when I started emacs.

This seems rather backward. I would have expected the issue that message
refers to to be the actual problem that you are seeing. There's no way
you can get that message in a non-GTK build. Maybe your system was
lacking the necessary libraries for a Lucid toolkit build and defaulted
to gtk? (I don't even know if that can happen.)

Please try a fresh Lucid build again, paying attention to the configure
output. Check in src/config.h that USE_GTK is not defined.

If that works, then I think it might be the same old gtk problem that
the message refers to.

If this issue affects gtk3 as well (I seem to recall it does?) then
emacs.c should also give that message for gtk3 (if it does not already).

Message #11 received at 9674 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Damien Cassou <damien.cassou <at> gmail.com>
Cc: 9674 <at> debbugs.gnu.org
Subject: Re: bug#9674: 24.0.90;
	Closing an emacsclient frame always kills daemon
Date: Wed, 05 Oct 2011 17:45:50 -0400

Damien Cassou <damien.cassou <at> gmail.com> writes:

> I open emacs with the following:
>
> emacsclient --alternate-editor="" -c ~/.bashrc
>
> According to the manual, it creates a daemon if none is running and
> then creates a client by connecting to this daemon. I confirm this
> behavior by looking at the running processes: I have one process for
> emacsclient and one for emacs --daemon. However, as soon as I close
> the last running emacsclient (with C-x C-c or C-x #), the daemon is
> also terminated.

FWIW, I can't reproduce this (with a GTK build).  After typing C-x # or
C-x C-c, the server is not killed; a subsequent invocation of
emacsclient (via "emacsclient -c ~/.bashrc") accesses the server as
expected.

Message #14 received at 9674 <at> debbugs.gnu.org (full text, mbox):

From: Damien Cassou <damien.cassou <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 9674 <at> debbugs.gnu.org
Subject: Re: bug#9674: 24.0.90;
	Closing an emacsclient frame always kills daemon
Date: Thu, 6 Oct 2011 13:28:28 +0200

On Wed, Oct 5, 2011 at 7:54 PM, Glenn Morris <rgm <at> gnu.org> wrote:
> This seems rather backward. I would have expected the issue that message
> refers to to be the actual problem that you are seeing. There's no way
> you can get that message in a non-GTK build. Maybe your system was
> lacking the necessary libraries for a Lucid toolkit build and defaulted
> to gtk? (I don't even know if that can happen.)

Ok, I understand. When I launch:

$ lib-src/emacsclient --alternate-editor="" -c ~/.bashrc

the daemon is created from /usr/bin/emacs and not from the ./src/emacs
that I have just compiled. I guess it's not possible to choose which
emacs to execute using this --alternate-editor parameter. Bug #9682
prevents me from testing with lucid.


-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

Message #17 received at 9674 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Damien Cassou <damien.cassou <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 9674 <at> debbugs.gnu.org
Subject: Re: bug#9674: 24.0.90;
	Closing an emacsclient frame always kills daemon
Date: Thu, 06 Oct 2011 11:17:14 -0400

Damien Cassou <damien.cassou <at> gmail.com> writes:

> When I launch:
>
> $ lib-src/emacsclient --alternate-editor="" -c ~/.bashrc
>
> the daemon is created from /usr/bin/emacs and not from the ./src/emacs
> that I have just compiled.

Yes, emacsclient runs just "emacs --daemon" in this case; it would not
be easy to get it to figure out how that it has to run a non-default
Emacs.

I don't understand why that would be a problem, though.  Are you saying
that when "emacs --daemon" is invoked in this way, subsequent attempts
to connect to the daemon from the same emacsclient fails?

Message #20 received at 9674 <at> debbugs.gnu.org (full text, mbox):

From: Damien Cassou <damien.cassou <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 9674 <at> debbugs.gnu.org
Subject: Re: bug#9674: 24.0.90;
	Closing an emacsclient frame always kills daemon
Date: Thu, 6 Oct 2011 18:22:56 +0200

On Thu, Oct 6, 2011 at 5:17 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> I don't understand why that would be a problem, though.  Are you saying
> that when "emacs --daemon" is invoked in this way, subsequent attempts
> to connect to the daemon from the same emacsclient fails?

No. I was just answering Glenn who was surprised that launching with
lucid toolkit prints the gtk warning message.

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

Previous Next

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