1
  1. Log into Gnome
  2. emacs-server is started by systemd, using the default configuration of my distribution (Fedora 36):
[Unit]
Description=Emacs text editor
Documentation=info:emacs man:emacs(1) https://gnu.org/software/emacs/

[Service]
Type=notify
ExecStart=/usr/bin/emacs --fg-daemon
ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
# The location of the SSH auth socket varies by distribution, and some
# set it from PAM, so don't override by default.
# Environment=SSH_AUTH_SOCK=%t/keyring/ssh
Restart=on-failure

[Install]
WantedBy=default.target
  1. Start an emacs-client frame using the Gnome shell.

At this point I can use magit and pull and push remote commits without typing my ssh key passphrase.

  1. Start an emacs frame (not a client) using the Gnome shell.

At this point I also can use my ssh key without typing the passphrase.

  1. Start an emacs-client frame using the Gnome shell.

I try to pull from my remote, emacs asks me for my ssh key passphrase.

I'm puzzled. I really would like to be able to continue using my ssh keys without typing the passphrase on subsequent emacs-client frames. This glitch becomes really annoying when I'm using emacs across multiple physical screens.

Gilles 'SO- stop being evil'
  • 21,702
  • 4
  • 53
  • 89
dmvianna
  • 370
  • 4
  • 21
  • Is `(emacs-pid)` returning the same value in both client frames? – phils Jul 11 '22 at 20:08
  • @phils no, I get different values. How do I fix that? I'm starting `emacs` with a desktop laucher using the command `emacsclient -c -a ""` – dmvianna Jul 11 '22 at 23:23
  • So that's the issue -- two independent Emacs instances/servers, only one of which knows about your SSH config. You'll have to check what "emacs-server is started by systemd" is actually doing. (I can't guess what that would be, sorry.) – phils Jul 12 '22 at 02:22
  • @phils I added the configuration above. – dmvianna Jul 12 '22 at 03:38
  • Oh, I can just create a new frame instead of starting a client! `Ctrl-x 5 2` or `make-frame` or `make-frame-on-monitor`... As usual, there's a command for it, but finding which one is the trick. – dmvianna Jul 12 '22 at 04:23
  • Sure. It doesn't solve the actual issue, though. I'd still want to find out why `emacsclient -c` isn't seeing the same server that your systemd thing is running. After all, you can close all your visible frames for a server, so being able to reconnect is important (IMO). – phils Jul 13 '22 at 01:38
  • @phils Happy to continue to bugtrack, but I don’t know where to look next. Can you provide guidance? – dmvianna Jul 13 '22 at 01:40
  • I would start by checking `C-h v server-socket-dir` in its server vs the one you started yourself. They're presumably different. Establishing what the differences are might point you in the right direction. (If they're *not* different then perhaps `C-h v server-name` is, but nothing you've shown suggests that to me.) – phils Jul 13 '22 at 02:01
  • Running `C-h v server-socket-dir` in the second frame (created via the Gnome shortcut) opens a buffer with the results on the first frame. So no problem there. Same if I run `emacsclient -c` from the terminal. So I can't reproduce the problem anymore. Win? – dmvianna Jul 13 '22 at 02:20

1 Answers1

2

The problem was that emacsd wasn't aware of $XAUTHORITY, which controls authentication within X. I now included it within the environment variables emacsd is aware of using exec-path-from-shell.

(use-package exec-path-from-shell
  :straight t
  :config
  (dolist (var '("PATH" "SSH_AUTH_SOCK" "SSH_AGENT_PID" "GPG_AGENT_INFO"
                 "LANG" "LC_CTYPE" "NIX_SSL_CERT_FILE" "NIX_PATH" "XAUTHORITY"))
    (add-to-list 'exec-path-from-shell-variables var))
  (exec-path-from-shell-initialize))

If you're wondering, I include $PATH so that lsp can find executables.

dmvianna
  • 370
  • 4
  • 21