This is totally a thought dump, as I just spent hours (!) figuring out why my environment had been persistently setting SSH_AUTH_SOCK across login sessions. It’s not a solution for readers’ particular issues, nor a tutorial on how to resolve my particular issue either: just a log of surprising things I found out today about a machine I’m, using.

The managed machine I’m using has switched to GDM3 as the display manager, and the default environment is GNOME3. I don’t enjoy GNOME3, and prefer i3 for work uses. I gave it a chance, but after restoring my homedir, I decided to go back to i3.

Note: During the homedir restoration, I had the GNOME3 session running. I moved my homedir away, signed out, and rsynced away. I hope this order of operation got GNOME3 confused and made it forget to clean things up.

Symptom: tools have been complaining they can’t talk to a valid-looking value for SSH_AUTH_SOCK. The socket file and its directory were both missing. ssh-agent was not running in the session.

• I use ~/.Xsession to configure my graphical session before starting i3. My first suspicion was something ran, set SSH_AUTH_SOCK and the ssh-agent crashed afterwards. This was not the case.
• I still had the terminal session running. It had an ssh-agent in it. Could that be the cause? No, after nuking the terminal session and signing in and out in the graphical one, the issue was stil present.
• Was ~/.Xsession supposed to execute /etc/X11/Xsession? No, that happens separately. This is fine.
• Is /etc/X11/Xsession.d/90x11-common_ssh-agent getting executed? Yes, it is. But $STARTUP is not getting updated. (Oh, right: /etc/X11/Xsession.d scripts on Debian OSes are not executing things directly, but scheduling later execution by updating envvarSTARTUP`.)
• Is /etc/X11/Xsession getting executed at all? At what point is SSH_AUTH_SOCK set? No, we are not running it at all. lightdm did (I think), but gdm3 has to be a special puppy.
• What’s executed instead? /etc/gdm3/Xsession which closely resembles /etc/X11/Xsession, but is not exactly the same.
• Is /etc/gdm3/Xsession executing /etc/X11/Xsession.d scripts? Yes, it is.
• So, which of the scripts is setting SSH_AUTH_SOCK? Well, in my individual situation, it looks like it’s happening before any of the script executes.
• Something in ~/.config? No. Envvar name or value not found.
• Something in ~/.local? No. Envvar name or value not found.
• Is something else run? Well, gnome-keychain-daemon is running for some reason and gets restarted upon session restart. It’s run by /etc/xdg/autostart/gnome-keyring-secrets.desktop file, and can be disabled by putting

  [Desktop Entry]
  Hidden=true
  # maybe other fields are required too?
  

  into ~/.config/autostart/gnome-keyring-secrets.desktop, blocking system file from starting up. (Remember, this is a managed machine; even if it weren’t, I don’t want to touch distribution-installed files.)

  However, no, blocking gnome-keyring-daemon from starting up doesn’t fix the issue.

So this is very confusing. A bad environment variable is surviving logout and seems set before any Xsession script is run.

Is gdm3 remembering things for us? Where would it be writing them anyway if not into homedir?

Turns out that no. gdm3 isn’t remembering anything.

Here’s what happened.

systemd can run in per-user mode (systemd --user). It keeps the environment in RAM and can also survive logouts. systemd --user is shared between all logged-in sessions of the current users.

The feature that caused trouble is — management of environment for daemons. systemctl --user show-environment shows that something wrote the entire environment of the GNOME3 session into systemd --user‘s environment. From what I can tell, all daemons started after login will inherit the environment from this. And it had rather ephemeral things like SSH_AUTH_SOCK, XAUTHORITY GPG_AGENT_INFO or XDG_SESSION_DESKTOP written into it!

Killing systemd --user process and restarting the session fixed everything. /etc/gdm3/Xsession no longer had SSH_AUTH_SOCK set when it started (in fact, it was not set by the time /etc/X11/Xsession.d/99x11-common_start was starting to read the $STARTUP envvar.

So, something in GNOME3 decided to write very ephemeral environment variables into systemd --user, never cleaned them up, and systemd --user did not get reaped even after I signed out from both the graphical and the terminal sessions! There’s a chance cleanup of systemd --user did not happen because the homedir was moved away at the time, but isn’t this stuff working with environment variables such as DBUS_SESSION_BUS_ADDRESS envvar, cat /run/systemd/user/$(id -u), /run/user/$(id -u) and other files under /run? How would have moving /home/${LOGNAME} prevented reaping of systemd --user?

I can see some value in these things being per-user rather than per-session, but given how systemd has been pushing for per-session stuff too, this is leaving a bad taste in the mouth, and makes me believe even further that systemd should not try to be “the runtime for Linux” (note, not the other OSes), it should not infect user sessions, and it should simply stick to what it does reasonably well: manage service startup. I really only want the ability to mount a mountpoint after a service has started, and to start a service after a mountpoint appeared. And otherwise similar dependencies on devices, perhaps.

I really don’t appreciate systemd getting into the business of managing cross-session environment variables. Is this why modern free software desktops refuse to start more than one session for a single user? I suspect so.

Previously, I didn’t think whatever we gained by giving up multiple-sessions-per-user was worth it, and after today, I’m not quite encouraged to give up on this gut feeling.

–
via blog.vucica.net