emacs service and session start

[Erwan David]

I enabled the emacs user service (starts emacs as daemon). The
ssh-agent is the one started by plasma. However, emacs (more exactly
tram in emacs) does not see the ssh-agent. If I restart the emacs
service once the session is on, it uses the keys inside. What should I
do to get correct ordering ?

I a on bookworm

[didier gaumet]

Post by Erwan David
I enabled the emacs user service (starts emacs as daemon). The
ssh-agent is the one started by plasma. However, emacs (more exactly
tram in emacs) does not see the ssh-agent. If I restart the emacs
service once the session is on, it uses the keys inside. What should I
do to get correct ordering ?
I a on bookworm

Hello,

Perhaps take a look at an explanation here on how to solve it:
https://fluca1978.github.io/2023/07/15/EmacsDaemonSystemDKDE.html

[Erwan David]

Post by didier gaumet

Post by Erwan David
I enabled the emacs user service (starts emacs as daemon). The
ssh-agent is the one started by plasma. However, emacs (more exactly
tram in emacs) does not see the ssh-agent. If I restart the emacs
service once the session is on, it uses the keys inside. What should I
do to get correct ordering ?
I a on bookworm

Hello,
https://fluca1978.github.io/2023/07/15/EmacsDaemonSystemDKDE.html

Thanks, looking at it, I think I'll need to do some overrides to the
unit provided by the package

[Erwan David]

Post by didier gaumet

    I enabled the emacs user service (starts emacs as daemon). The
ssh-agent is the one started by plasma. However, emacs (more exactly
tram in emacs) does not see the ssh-agent. If I restart the emacs
service once the session is on, it uses the keys inside. What should I
do to get correct ordering ?
I a on bookworm

Hello,
https://fluca1978.github.io/2023/07/15/EmacsDaemonSystemDKDE.html

Ok, it could work, ilf only ssh-agent was not started with a random
socket name...

And I do not see what starts it (I see the process ssh-agent
/usr/bin/startplasma-x11 but I did not find which service starts it)

[Max Nikulin]

Post by Erwan David
Ok, it could work, ilf only ssh-agent was not started with a random
socket name...
And I do not see what starts it (I see the process ssh-agent
/usr/bin/startplasma-x11 but I did not find which service starts it)

It is started by /etc/X11/Xsession.d/90x11-common_ssh-agent
The question is why emacs.service is started before
/usr/lib/openssh/agent-launch or plasma copies SSH_AUTH_SOCKET value to
systemd environment. You may try to suppress starting of ssh-agent
through Xsession and use either ssh-agent.service or

systemctl --user list-sockets '*ssh*'
LISTEN UNIT ACTIVATES
/run/user/1000/gnupg/S.gpg-agent.ssh gpg-agent-ssh.socket gpg-agent.service

[Max Nikulin]

Post by Max Nikulin

Post by Erwan David
Ok, it could work, ilf only ssh-agent was not started with a random
socket name...
And I do not see what starts it (I see the process ssh-agent
/usr/bin/startplasma-x11 but I did not find which service starts it)

It is started by /etc/X11/Xsession.d/90x11-common_ssh-agent
The question is why emacs.service is started before
/usr/lib/openssh/agent-launch or plasma copies SSH_AUTH_SOCKET value to
systemd environment.

Looking into "journalctl --user -b" and checking environment of
processes started before and after "Started dbus.service - D-Bus User
Message Bus.", it should be enough to add a drop-in for emacs.service with

After=dbus.service
Wants=dbus.service

or Requires instead of Wants.

emacs.service may be started lazily by adding emacs.socket. However unit
dependency should be explicitly set anyway.

[Erwan David]

Post by Max Nikulin

Post by Erwan David
Ok, it could work, ilf only ssh-agent was not started with a random
socket name...
And I do not see what starts it (I see the process ssh-agent
/usr/bin/startplasma-x11 but I did not find which service starts it)

It is started by /etc/X11/Xsession.d/90x11-common_ssh-agent
The question is why emacs.service is started before
/usr/lib/openssh/agent-launch or plasma copies SSH_AUTH_SOCKET value to
systemd environment.

Looking into "journalctl --user -b" and checking environment of processes
started before and after "Started dbus.service - D-Bus User Message Bus.",
it should be enough to add a drop-in for emacs.service with
After=dbus.service
Wants=dbus.service
or Requires instead of Wants.
emacs.service may be started lazily by adding emacs.socket. However unit
dependency should be explicitly set anyway.

Thanks, I'll try it (and if it works, I'll do a reportbug so that the
unit in the package is modified)

[Erwan David]

Post by Erwan David

Post by Max Nikulin

Post by Erwan David
Ok, it could work, ilf only ssh-agent was not started with a random
socket name...
And I do not see what starts it (I see the process ssh-agent
/usr/bin/startplasma-x11 but I did not find which service starts it)

It is started by /etc/X11/Xsession.d/90x11-common_ssh-agent
The question is why emacs.service is started before
/usr/lib/openssh/agent-launch or plasma copies SSH_AUTH_SOCKET value to
systemd environment.

Looking into "journalctl --user -b" and checking environment of processes
started before and after "Started dbus.service - D-Bus User Message Bus.",
it should be enough to add a drop-in for emacs.service with
After=dbus.service
Wants=dbus.service
or Requires instead of Wants.
emacs.service may be started lazily by adding emacs.socket. However unit
dependency should be explicitly set anyway.

Thanks, I'll try it (and if it works, I'll do a reportbug so that the
unit in the package is modified)

Alas it does not work. I disabled the service, and added a systemctl
--user start emacs at session start.

This works

PS: It works on a testing, so there may be a difference

[Max Nikulin]

Post by Erwan David

Post by Max Nikulin
It is started by /etc/X11/Xsession.d/90x11-common_ssh-agent
The question is why emacs.service is started before
/usr/lib/openssh/agent-launch or plasma copies SSH_AUTH_SOCKET value to
systemd environment.

[...]

Post by Erwan David
Alas it does not work.

Sounds like a race between code that copies environment and starting
emacs. Have you tried to disable ssh-agent in Xsession to start it from
systemd? Without it I am not sure that the following is really reliable:

[Unit]
After=dbus.service ssh-agent.service
Wants=dbus.service ssh-agent.service
[Install]
WantedBy=
WantedBy=graphical-session-pre.target

[Erwan David]

Post by Erwan David

Post by Max Nikulin
It is started by /etc/X11/Xsession.d/90x11-common_ssh-agent
The question is why emacs.service is started before
/usr/lib/openssh/agent-launch or plasma copies SSH_AUTH_SOCKET value to
systemd environment.

[...]

Post by Erwan David
Alas it does not work.

Sounds like a race between code that copies environment and starting emacs.
Have you tried to disable ssh-agent in Xsession to start it from systemd?
[Unit]
After=dbus.service ssh-agent.service
Wants=dbus.service ssh-agent.service
[Install]
WantedBy=
WantedBy=graphical-session-pre.target

After some investigations :
plasma uses le /etc/X11/Xsession script, which sources
/etc/X11/Xsession.d/*

In the sourced snippets is /etc/X11/Xsession.d/90x11-common_ssh-agent

The effect is that if /etc/Xsession.options sets use-ssh-agent, it
starts plasma with the ssh-agent startplasmax11 command. Thus, systemd
is given the SSH_AUTH_SOCK variable (and the sock is at a random place
under /tmp)

Then ssh-agent.service seems to do nothing since ssh-agent is already started

Setting no-use-ssh-agent in /etc/X11/Xsession.option is a no go : it
is also tested by ssh-agent.service

Only solutions I see would imply modifying
/etc/X11/Xsession.d/90x11-common_ssh-agent, but is it a configuration
file ?

[Max Nikulin]

Post by Erwan David

Post by Max Nikulin

Post by Max Nikulin
It is started by /etc/X11/Xsession.d/90x11-common_ssh-agent

[Unit]
After=dbus.service ssh-agent.service
Wants=dbus.service ssh-agent.service
[Install]
WantedBy=
WantedBy=graphical-session-pre.target

[...]

Post by Erwan David
In the sourced snippets is /etc/X11/Xsession.d/90x11-common_ssh-agent
The effect is that if /etc/Xsession.options sets use-ssh-agent, it
starts plasma with the ssh-agent startplasmax11 command. Thus, systemd
is given the SSH_AUTH_SOCK variable (and the sock is at a random place
under /tmp)

I have had a look into startplasma sources. It pushes environment to
systemd *before* initiating plasma-workspace-x11.target. (My additional
interest was the following: If some variable is set in both ~/.profile
and environment.d, what value wins?)

Post by Erwan David
Setting no-use-ssh-agent in /etc/X11/Xsession.option is a no go : it
is also tested by ssh-agent.service

It seems /usr/lib/openssh/agent-launch checks /etc/X11/Xsession.options,
but not /etc/X11/Xsession.options.d. However it would be a rather
fragile hack.

Post by Erwan David
Only solutions I see would imply modifying
/etc/X11/Xsession.d/90x11-common_ssh-agent, but is it a configuration
file ?

Ask "dpkg -s PKG" or dpkg-query with some options.

Do you really need emacs as a part of default.target and
graphical-session.target is too late for you? The override for
emacs.service, I posted earlier, should work otherwise.

As an alternative I would consider configuring either ssh-agent.service
or a dedicated unit to execute in addition 'emacsclient --eval "(putenv
...)"'. See emacsclient-mailto.desktop how escape argument for Emacs-28.

[Erwan David]

Post by Erwan David

Post by Max Nikulin

Post by Max Nikulin
It is started by /etc/X11/Xsession.d/90x11-common_ssh-agent

[Unit]
After=dbus.service ssh-agent.service
Wants=dbus.service ssh-agent.service
[Install]
WantedBy=
WantedBy=graphical-session-pre.target

[...]

Post by Erwan David
In the sourced snippets is /etc/X11/Xsession.d/90x11-common_ssh-agent
The effect is that if /etc/Xsession.options sets use-ssh-agent, it
starts plasma with the ssh-agent startplasmax11 command. Thus, systemd
is given the SSH_AUTH_SOCK variable (and the sock is at a random place
under /tmp)

I have had a look into startplasma sources. It pushes environment to systemd
*before* initiating plasma-workspace-x11.target. (My additional interest was
the following: If some variable is set in both ~/.profile and environment.d,
what value wins?)

Post by Erwan David
Setting no-use-ssh-agent in /etc/X11/Xsession.option is a no go : it
is also tested by ssh-agent.service

It seems /usr/lib/openssh/agent-launch checks /etc/X11/Xsession.options, but
not /etc/X11/Xsession.options.d. However it would be a rather fragile hack.

Post by Erwan David
Only solutions I see would imply modifying
/etc/X11/Xsession.d/90x11-common_ssh-agent, but is it a configuration
file ?

Ask "dpkg -s PKG" or dpkg-query with some options.
Do you really need emacs as a part of default.target and
graphical-session.target is too late for you? The override for
emacs.service, I posted earlier, should work otherwise.
As an alternative I would consider configuring either ssh-agent.service or a
dedicated unit to execute in addition 'emacsclient --eval "(putenv ...)"'.
See emacsclient-mailto.desktop how escape argument for Emacs-28.

The after/wants does not work (starnge since ssh-agent.service seems
to see the SSH_AUTH_SOCK variable.

But /etc/X11/Xsession.d/90x11-common_ssh-agent is a configuration file
and we can add SSHARGS. I added a
SSHARGS="-a $XDG_RUNTIME_DIR/ssh-agent"

Then I added an override to emacs.service
Environment=SSH_AUTH_SOCK=%t/ssh-agent

And it works

[Greg Wooledge]

Post by Erwan David
The after/wants does not work (starnge since ssh-agent.service seems
to see the SSH_AUTH_SOCK variable.
But /etc/X11/Xsession.d/90x11-common_ssh-agent is a configuration file
and we can add SSHARGS. I added a
SSHARGS="-a $XDG_RUNTIME_DIR/ssh-agent"
Then I added an override to emacs.service
Environment=SSH_AUTH_SOCK=%t/ssh-agent
And it works

It's amazing how badly the systemd folks managed to break *everything*.

I'm pretty old-fashioned. I use startx from a console login, and I
configure it with a ~/.xsession file which overrides the Debian stuff.

In my .xsession file I have:

hash ssh-agent 2>/dev/null && eval "$(ssh-agent -s)"
hash ssh-add 2>/dev/null && ssh-add </dev/null

This launches an agent, and evaluates the output (variables defining
where the socket lives), exactly the way it's supposed to be done since
decades before systemd existed.

I invoke my window manager later in the .xsession file, so it inherits
the ssh-agent environment variables. All of my X11 programs are children
of the window manager (or of this .xsession file), so *they* all inherit
the variables as well.

None of that "child of dbus" or "child of systemctl --user" bullshit
for me, thank you very much.

[Max Nikulin]

Erwan, maybe you forgot to do disable/enable cycle after adjusting
"[Install]" section of the unit configuration.

systemctl --user list-dependencies --reverse emacs.service

Post by Greg Wooledge
It's amazing how badly the systemd folks managed to break *everything*.
I'm pretty old-fashioned. I use startx from a console login, and I
configure it with a ~/.xsession file which overrides the Debian stuff.

I have no idea if it is intentional, but emacs.service is not specific
to graphical sessions. By default (when enabled) it is started even in
the case of e.g. ssh login. So you may use single emacs daemon instance
having multiple simultaneous logins. It is stopped on last logout.
ssh-agent may be started after emacs and it is possible to notify emacs
where is current agent socket.

Concerning graphical sessions, when you click in a browser on a link to
download a document that should be opened in LibreOffice, should it
inherit environment from browser or should it be started with clean
session environment? What if the browser is running in a highly isolated
sandbox and there is no LibreOffice in the accessible part of its
filesystem? So some intermediate instance that can handle requests to
launch other applications becomes necessary. Of course, new
possibilities add some complexity.

[Max Nikulin]

Post by Erwan David

Post by Max Nikulin
[Unit]
After=dbus.service ssh-agent.service
Wants=dbus.service ssh-agent.service
[Install]
WantedBy=
WantedBy=graphical-session-pre.target

[...]

Post by Erwan David
The after/wants does not work (starnge since ssh-agent.service seems
to see the SSH_AUTH_SOCK variable.

Have you checked that emacs.service is started at proper moment
(journalctl --user)? At first I did not add empty WantedBy and it caused
earlier start of ssh-agent.service instead of delay of emacs.service.

It might be reasonable to start emacs from default.target, e.g. for ssh
logins (however emacs.socket to start it on demand might be better) and
updating environment using "emacsclient --eval" sounds viable.

Notice that other KDE-specific configuration (~/.config/plasma-localerc,
~/.config/plasma-workspace/env) or ~/.profile sourced by SDDM may be
ignored by emacs in the case of early start.

[Erwan David]

Have you checked that emacs.service is started at proper moment (journalctl
--user)? At first I did not add empty WantedBy and it caused earlier start
of ssh-agent.service instead of delay of emacs.service.
It might be reasonable to start emacs from default.target, e.g. for ssh
logins (however emacs.socket to start it on demand might be better) and
updating environment using "emacsclient --eval" sounds viable.
Notice that other KDE-specific configuration (~/.config/plasma-localerc,
~/.config/plasma-workspace/env) or ~/.profile sourced by SDDM may be ignored
by emacs in the case of early start.

You are right, I did not think to check journal...

Aug 30 13:29:25 lp053 systemd[1]: Started ***@1000.service - User Manager for UID 1000.
Aug 30 13:29:25 lp053 systemd[1767]: Starting emacs.service - Emacs text editor...
^^^^^^^^^^ Too early ^^^^^^^^^^^
Aug 30 13:29:25 lp053 systemd[1767]: Starting pulseaudio.service - Sound Service...
Aug 30 13:29:25 lp053 systemd[1]: Started session-3.scope - Session 3 of User erwan.
Aug 30 13:29:25 lp053 rtkit-daemon[1659]: Successfully made thread 1786 of process 1786 owned by '1000' high priority at nice level -11.
Aug 30 13:29:25 lp053 rtkit-daemon[1659]: Supervising 1 threads of 1 processes of 1 users.
Aug 30 13:29:25 lp053 sddm-helper[1795]: pam_kwallet5: final socket path: /run/user/1000/kwallet5.socket
Aug 30 13:29:25 lp053 sddm-helper[1764]: pam_env(sddm:session): deprecated reading of user environment enabled
Aug 30 13:29:25 lp053 sddm-helper[1764]: Starting: "/etc/sddm/Xsession \"/usr/bin/startplasma-x11\""
Aug 30 13:29:25 lp053 sddm-helper[1797]: Adding cookie to "/home/erwan/.Xauthority"
Aug 30 13:29:25 lp053 sddm[1301]: Session started
Aug 30 13:29:25 lp053 systemd[1767]: Starting dbus.service - D-Bus User Message Bus...
Aug 30 13:29:25 lp053 systemd[1767]: Started dbus.service - D-Bus User Message Bus.
Aug 30 13:29:25 lp053 emacs[1785]: Warning: due to a long standing Gtk+ bug
Aug 30 13:29:25 lp053 emacs[1785]: https://gitlab.gnome.org/GNOME/gtk/issues/221
Aug 30 13:29:25 lp053 emacs[1785]: Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
Aug 30 13:29:25 lp053 emacs[1785]: Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
Aug 30 13:29:25 lp053 rtkit-daemon[1659]: Supervising 1 threads of 1 processes of 1 users.
Aug 30 13:29:25 lp053 rtkit-daemon[1659]: Successfully made thread 1846 of process 1786 owned by '1000' RT at priority 5.
Aug 30 13:29:25 lp053 rtkit-daemon[1659]: Supervising 2 threads of 1 processes of 1 users.
Aug 30 13:29:25 lp053 rtkit-daemon[1659]: Supervising 2 threads of 1 processes of 1 users.
Aug 30 13:29:26 lp053 rtkit-daemon[1659]: Successfully made thread 1850 of process 1786 owned by '1000' RT at priority 5.
Aug 30 13:29:26 lp053 rtkit-daemon[1659]: Supervising 3 threads of 1 processes of 1 users.
Aug 30 13:29:26 lp053 systemd[1767]: Reloading requested from client PID 1797 ('startplasma-x11')...
Aug 30 13:29:26 lp053 systemd[1767]: Reloading...


(thats without the require/wants) I'll continue investigating in this direction.