Tested the new version and updated configuration with dispatch-conf. Found that whilst I was able to start Emacs daemon I couldn't connect to it as there was no /run/user/1000/emacs/server file created. I typically connect with... /usr/bin/emacs-client -nw --socket-name=${EMACS_SOCKET} ...where ${EMACS_SOCKET} is set to /run/user/1000/emacs/server Reverted to =app-emacs/emacs-server-0.22-r1 and updated configuration and no problems. Checked the commit (https://gitweb.gentoo.org/proj/emacs-tools.git/commit/?h=emacs-daemon&id=4679ffa22311bbbff28e2a8caeb694a5b09c7c3c) and saw the entries in the ChangeLog + * emacs.rc (EMACS_OPTS): Use --fg-daemon instead of --daemon. + (EMACSCLIENT): Remove. + (start, stop): Don't export EMACS_DEBUG, EMACSCLIENT and + EMACSCLIENT_OPTS. + (start): Call start-stop-daemon with options --background and + --make-pidfile. Unset XDG_RUNTIME_DIR because it points to the + directory of the superuser and is not writable for us. + * emacs.conf: Update accordingly. + * emacs-wrapper.sh: Simplify; keep only the login shell wrapper. + * 10emacs-daemon-gentoo.el: Don't write the pid file, as this is + now handled by OpenRC's start-stop-daemon command. + ...but no mention of changes to where server is written. I've probably missed/misunderstood something and need to change my configuration.
(In reply to Neil from comment #0) > Found that whilst I was able to start Emacs daemon I couldn't connect to it > as there was no /run/user/1000/emacs/server file created. > > I typically connect with... > > /usr/bin/emacs-client -nw --socket-name=${EMACS_SOCKET} > > ...where ${EMACS_SOCKET} is set to /run/user/1000/emacs/server Not sure how this could have worked before; the intended location for creation of the socket was always "/tmp/emacs$(id -ru)/server". Where did OpenRC (or the startup wrapper script) get the /run/user/1000 location from? This seems to imply that XDG_RUNTIME_DIR was set. Please try the following: - Can you connect with "emacsclient -nw --socket-name=/tmp/emacs1000/server"? - If yes, what does "M-x getenv RET XDG_RUNTIME_DIR RET" output? - Same for "M-x getenv RET EMACS_SOCKET_NAME RET"
(In reply to Ulrich Müller from comment #1) > Please try the following: > - Can you connect with "emacsclient -nw --socket-name=/tmp/emacs1000/server"? > - If yes, what does "M-x getenv RET XDG_RUNTIME_DIR RET" output? > - Same for "M-x getenv RET EMACS_SOCKET_NAME RET" One further test: - Edit /etc/init.d/emacs and find the "unset XDG_RUNTIME_DIR" line - Insert the following line before it: einfo "XDG_RUNTIME_DIR=${XDG_RUNTIME_DIR}" - What does it say when you start the daemon?
Hi, Thanks for taking the time to look at this. Under =app-emacs/emacs-daemon-0.22-r1 I have no options set... # /etc/conf.d/emacs: config file for /etc/init.d/emacs.<user> # This can also be used as multiplexed configuration, i.e. openrc-run # looks for both /etc/conf.d/emacs and /etc/conf.d/emacs.<user>. # Absolute path to the emacs and emacsclient binaries #EMACS="/usr/bin/emacs" #EMACSCLIENT="/usr/bin/emacsclient" # Emacs detaches and exits the parent process only after loading the # user's .emacs (initialisation). Anything may happen there, so we use # a wrapper script to ensure that the Emacs daemon properly starts. # This also executes a login shell to read the user's profile. #246460 #EMACS_START="/usr/libexec/emacs/emacs-wrapper.sh" # Optionally, you may execute a custom script before stopping the # daemon. See /usr/libexec/emacs/emacs-stop.sh for an example. #246462 #EMACS_STOP="" # Timeout (in seconds) to wait for the daemon to detach #EMACS_TIMEOUT="30" # Options to pass to emacs. Don't remove "--daemon". #EMACS_OPTS="--daemon" # Options to pass to emacsclient. This variable is only used if you # call emacsclient from a custom stop script, see EMACS_STOP above. #EMACSCLIENT_OPTS="" # The SHELL variable to be passed to EMACS_START. emacs-wrapper.sh uses # this as the user's login shell. If (explicitly set to) empty, then # the shell field from the passwd file is used. #EMACS_SHELL="/bin/bash" # Enable additional output for debugging. #EMACS_DEBUG="" ...and on starting the server is at /run/users/1000/emacs/server # l /run/user/1000/emacs/ total 0 drwx------ 2 neil neil 60 Mar 6 21:05 . drwx------ 10 neil neil 220 Mar 2 11:31 .. srwx------ 1 neil neil 0 Mar 6 21:05 server Upgrade to =app-emacs/emacs-daemon-0.23 and dispatch-conf to update /etc/conf.d/emacs # /etc/conf.d/emacs: config file for /etc/init.d/emacs.<user> # This can also be used as multiplexed configuration, i.e. openrc-run # looks for both /etc/conf.d/emacs and /etc/conf.d/emacs.<user>. # Absolute path to the emacs binary #EMACS="/usr/bin/emacs" # Options to pass to emacs. Don't remove "--fg-daemon". #EMACS_OPTS="--fg-daemon" # Emacs detaches and exits the parent process only after loading the # user's .emacs (initialisation). Anything may happen there, so we use # a wrapper script to ensure that the Emacs daemon properly starts. # This also executes a login shell to read the user's profile. #246460 #EMACS_START="/usr/libexec/emacs/emacs-wrapper.sh" # Optionally, you may execute a custom script before stopping the # daemon. #246462 #EMACS_STOP="" # Timeout (in seconds) to wait for termination of the daemon #EMACS_TIMEOUT="30" # The SHELL variable to be passed to EMACS_START. emacs-wrapper.sh uses # this as the user's login shell. If (explicitly set to) empty, then # the shell field from the passwd file is used. #EMACS_SHELL="/bin/bash" # rc-service emacs.neil restart * Caching service dependencies ... [ ok ] * Executing: /usr/libexec/rc/sh/openrc-run.sh /usr/libexec/rc/sh/openrc-run.sh /etc/init.d/emacs stop * Stopping Emacs daemon for user neil ... * Will stop /usr/bin/emacs * Will stop PID 2241 * Will stop processes owned by UID 1000 * Will stop processes of `/usr/bin/emacs' * Sending signal 15 to PID 2241 ... [ ok ] * Executing: /usr/libexec/rc/sh/openrc-run.sh /usr/libexec/rc/sh/openrc-run.sh /etc/init.d/emacs start * Starting Emacs daemon for user neil ... * start-stop-daemon: fopen `/var/run/emacs/neil/emacs.pid': No such file or directory * Detaching to start `/usr/libexec/emacs/emacs-wrapper.sh' ... [ ok ] I can indeed (as user `neil`) connect with emacsclient -nw --socket-name=/tmp/emacs1000/server From the user connected `M-x getenv RET XDG_RUNTIME_DIR RET` results in `Match required` the only environment variables Emacs can see are... XDG_DATA_DIRS XDG_CONFIG_DIRS XDG_CONFIG_HOME It _is_ defined under `root` though... # echo $XDG_RUNTIME_DIR /run/user/1000 From the user connected Emacs `M-x getenv RET EMACS_SOCKET_NAME RET` this isn't defined either although again it exists under `root` # echo $EMACS_SOCKET /run/user/1000/emacs/server Checking the value of XDG_RUNTIME_DIR on restarting the service shows * XDG_RUNTIME_DIR=/run/user/1000 ...and when unset, unsurprisingly, emacsclient -nw --socket-name=/run/user/1000/server connects again. I guess I've got something weird going on with XDG_RUNTIME_DIR?
(In reply to Neil from comment #3) > It _is_ defined under `root` though... > > # echo $XDG_RUNTIME_DIR > /run/user/1000 How did you login as root? Console login, su, sudo, ssh? > I guess I've got something weird going on with XDG_RUNTIME_DIR? XDG_RUNTIME_DIR for root (if it is even set) would have a value of /run/user/0, not /run/user/1000 (with 1000 being the UID of user neil, I suppose). The point is that we cannot rely on it having any specific value. Especially, at system startup it won't point to your user dir. For some background information, see https://debbugs.gnu.org/33847 and https://debbugs.gnu.org/51327. tl;dr The workaround is not to rely on XDG_RUNTIME_DIR, but assign EMACS_SOCKET_NAME in (e.g.) your ~/.profile file, like this: export EMACS_SOCKET_NAME="/tmp/emacs$(id -ru)/server"
> tl;dr The workaround is not to rely on XDG_RUNTIME_DIR, but assign > EMACS_SOCKET_NAME in (e.g.) your ~/.profile file, like this: > > export EMACS_SOCKET_NAME="/tmp/emacs$(id -ru)/server" Ping. Does this fix the problem for you?
Sorry wrote a reply got distracted and list it. Yes that has worked, I used to have a custom line in my .zshrc for setting alias' on a per host basis until I standardised everything across machines. Reinstated that and adjusted appropriately for the given location. Thanks for taking the time to look at this and for the explanation and solution, appreciated.
Closing. I should also point out that OpenRC 0.60 supports user sessions as an experimental feature: "openrc now supports running services in a user session via the --user flag and an optional pam module". (It doesn't quite work yet in openrc-0.60.1, but you can try openrc-9999 if you're feeling adventurous. :) See README.daemon in the documentation of app-emacs/emacs-common-1.11 for more info.
Thanks for the pointer to new/upcoming features of OpenRC will definitely check that out as the ability for user to start/control OpenRC is something I've been missing (I use --user to manage Emacs services under Arch Linux on work laptop).
