2

Background:

I want to use emacs like tmux which can run as persistent session as well as shorten the time for me to start bringing up emacs when I want to (as inspired by these: Emacs and a Tmux replacement and Detaching and re-attaching to emacs server )

In my .profile, I tried to start emacs in daemon mode in the background, and it didn't start, and there was this message:

 http://bugzilla.gnome.org/show_bug.cgi?id=85715
 Emacs might crash when run in daemon mode and the X11 connection is unexpecedly lost.
 Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.

Then I start emacs with -Q --debug-init --daemon --with-x-toolkit=lucid.

But the process hangs there as well as my logging in.

When I check with tty1, I see always 2 pairs of processes:

 14183 ?        Sl     0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
 14187 ?        Sl     0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
 14132 ?        S    0:00 /usr/bin/emacs -Q --debug-init --daemon --with-x-toolkit=lucid
 14138 ?        Ssl    0:00 /usr/bin/emacs -Q --debug-init --daemon --with-x-toolkit=lucid

And if I kill one of the emacs process (usually with the single S), then the other keyring-daemon process will disappear and I will be automatically brought back to the logon screen and the logon will be successful too. One examination with ps x in the Xsession, there is only 1 emacs process and only 1 keyring process.

Questions:

  1. What is happening so that the emacs startup hangs?

  2. What can I do in my settings to make the emacs daemon startup nicely?

[I am using Emacs 25.1.1 on all most updated Devuan ASCII 2.1 distro (I know, my distro "Devuan" is so slow to update packages)]

Edit 1: After I have fully started X and in XWindows environment, and if I do a $> killall emacs first and make sure no emacs process is running, and then try starting the daemon with the same line. Here is the result:

 My_User_Name@devux:~$ emacs --daemon
 Warning: due to a long standing Gtk+ bug
 bugzilla.gnome.org/show_bug.cgi?id=85715
 Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
 Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.

(and then starting my site-list and then .emacs etc.)

 Starting Emacs daemon.

 My_User_Name@devux:~$ ps x | grep emacs
 17553 ? Ssl 0:06 emacs --debug-init --daemon
 18843 pts/0 S+ 0:00 grep --color=auto emacs

Edit 2: On further trial-and-error, I move the emacs --daemon from .profile to .xsessionrc, and then to the startup tab of xfce4-session-settings. And there is no hiccup for starting the daemon or for the login. I will investigate further for the actual reasons. [By the way, having the emacs daemon started does some convenience for me: my emacs startup time is beyond 12-15 seconds, and now with emacsclient -c -q, I can bring up a frame in less than a second and emacs serves also some functions like tmux in the background.]

Improve this question
8
  • After your desktop is properly started, start emacs --daemon (from one shell window). Ignore any messages/warnings and start emacsclient (from another shell). What happens?
    – Rusi
    Commented Jan 25, 2020 at 6:19
  • But what about «emacsclient file.txt» thereafter? (It's better to update the question than to put these sorts of things in comments)
    – Rusi
    Commented Jan 25, 2020 at 12:36
  • @Rusi If I do not start emacs (while the emacs daemon or the two of them are running) Where am I supposed to find this emacsclient file.txt ?
    – menuhin
    Commented Jan 27, 2020 at 20:40
  • emacsclient is a program the way emacs is. You should find it where you find emacs, most likely /usr/bin. Or you can do "which emacsclient" or "which emacs" and you'll get the path on your machine. But pragmatically it's none of your business 😉. If "emacs" command works so will "emacsclient". (file.txt is some existing file of yours)
    – Rusi
    Commented Jan 28, 2020 at 2:52
  • Instead of "emacsclient file.txt" you can use it with various switches such as -c -n. See gnu.org/software/emacs/manual/html_node/emacs/…
    – Rusi
    Commented Jan 28, 2020 at 4:10

2 Answers 2

Reset to default
1

Don't use all those options at once; some of them are doing incompatible things:

  • --debug-init loads emacs, and stops with a stack trace if it encounters a problem. If it's in daemon mode, you won't see this, so won't know anything unexpected has happened. Thus, it will seem as if Emacs has crashed or become unresponsive. Also, if you are debugging your init, you need to actually load your init. That means you can't use the --Q option (see next)

  • -Q means don't load any of your configuration files. Which are the things that debug-init is trying to debug. You only use -Q when you think you have an emacs bug to sort out, not when you want to load a normal Emacs session

  • --daemon loads Emacs to run as a server in the background. This will be a problem if emacs encounters any problems during start up. When it does, it will often ask the user for some input.

  • --with-x-toolkit=lucid is a compile option. It doesn't do anything useful when you try to start emacs. It might cause problems, if Emacs interprets it as the name of a file it should open. This could generate a problem, and if Emacs is trying to start in daemon mode you won't see any visible sign of the problem.

What should you actually be doing? First, make sure Emacs starts normally when you call it from the command line with regular emacs (i.e., no options).

If there are any errors, you'll need to fix these before trying to use daemon mode. You can ignore the warning about the lucid toolkit, if that's the only problem you see. (you can fix that by recompiling emacs yourself, but it's probably not necessary).

Once you confirm that emacs loads a properly configured emacs session, you can close that session and try starting the daemon: emacs --daemon. Then check that you can open a new client via emacsclient. If that works, you can add emacs --daemon to the appropriate spot to have it start when you login (which could be .profile, or wherever your desktop manager looks for files to start at login.

Improve this answer
4
  • Thanks for the canonical answer, and for actually trying to help via explanations of your understanding of each of the options. My emacs starts with no problem since the era of version 20 - and I always tried to fix any startup problem, though not an elisp expert myself. I tried those options which I kind of know via briefly consulting manpages because I am desperate to have a lean daemon run in the background. My emacs start correctly, taking around 15-20 seconds, and the emacs --daemon runs too once when I am already inside X and of course I can start the emacsclient afterwards.
    – menuhin
    Commented Jan 28, 2020 at 16:46
  • That "appropriate spot" is not my .profile, and not my .xsessionrc -- starting the emacs daemon at these two locations will crash my login: once I have typed my password and pressed return on the login screen, it takes a while, and then will bring me back to the username-password login screen. And somehow I can login to X successfully at a second attempt; and by monitoring via a terminal on tty1, I could say the daemon was started during the first tried-but-failed login attempt, but the intriguing part is that there was not only one but two emacs --daemon processes started.
    – menuhin
    Commented Jan 28, 2020 at 16:49
  • On further trial-and-error, I move the emacs --daemon from .xsessionrc to the startup tab of xfce4-session-settings. And there is no hiccup for starting the daemon or for the login. I will investigate further for the actual reasons.
    – menuhin
    Commented Jan 28, 2020 at 16:50
  • what the appropriate spot is will depend on your system. I use the i3wm, and have it set to run a script when I login - that's where I put my emacs --daemon call. It will be different for other window managers. Another thing to try: make sure you add an &: emacs --daemon &. Without that, your startup might hang waiting for emacs --daemon to finish, which it won't, at least if it trys to prompt the user for any information.
    – Tyler
    Commented Jan 28, 2020 at 18:49
0

I’m not super sure this is an emacs issue. Here are some things to try:

  1. I think your .profile file can be run a bunch of times. Maybe try moving that command into your .xprofile
  2. Maybe just set your EDITOR to "emacsclient -ca=". Then the emacs will start whenever you actually want to use it. But maybe you want to have emacs do things in the background.
Improve this answer
4
  • I want to add emacs --daemon to minimize emacs loading time. What are the possible reasons that my .profile is run for a bunch of times instead of just once.
    – menuhin
    Commented Jan 25, 2020 at 12:10
  • I don’t have a good reason as to why it would be run multiple times. Maybe you use a login shell in your gui terminal. Maybe you log into a terminal as well as X. Maybe it’s run when you log in and when X starts. All I’m suggesting is that I wouldn’t rely on it being run only once. FWIW I don’t do this because it doesn’t change start up times for me because I’m going to start emacs immediately anyway, and the times don’t matter as I’m only going to start it roughly once a week.
    – Dan Robertson
    Commented Jan 25, 2020 at 13:22
  • I have only that line of emacs starting as a daemon on my .profile and nowhere else (e.g. xsession, etc.), and when I do a $> sh .profile , it always resulted in 2 emacs processes. It is still a mysterious. Starting emacs only ~once a week is best, but I do this because I am still actively changing my dot-emacs and other settings and those add-hook and mode-hook things cannot be cleared out so easily (if I just keep adding). So I prefer running a daemon in case I have to restart emacs again.
    – menuhin
    Commented Jan 27, 2020 at 20:38
  • Also, emacs --daemon exists for some reasons, and for other convenience, other than just cutting the startup time.
    – menuhin
    Commented Jan 27, 2020 at 20:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.