Tag Archives: X11

Random notes on GNOME, GDM3, systemd –user and ephemeral environment variables such as SSH_AUTH_SOCK

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]
    # 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.

Zagreb's Public Transportation device details

Ako se pitate što vrte ZETovi tramvaji, to jest uređaji za poništavanje karata, čitajte dalje.
Rest of this post is in English.

Ticket checkout devices installed during 2009 in Zagreb’s trams and buses are already known to run X Window System. I have identified and photographed it during an obvious malfunction. Another one has happened today.

In a tram on line 4, I took the shots attached to this post. They identify the hardware as running on Atmel’s BIOS. CPU is also Atmel’s; they contain AT91SAM9263 CPU at 200 MHz. Devices contain 64MB of SDRAM, and for storage purposes, 256 MB of NAND flash. They seem run U-Boot 1.1.5 from May 2 2008. At least I think that’s a U; as you can see it was sliced off. Screen calibration fail, much?

Because it runs U-Boot, they also probably run Linux, on which they run X11, on which they run their custom GUI.

For those who don’t know (those outside Zagreb), these are new smartcard-reading devices used to track “subscribers” and to charge “non-subscribers”. You’re supposed to put your card on the device in order for it to scan your ZET-issued smartcard, and charge you/record your movement accordingly.

Some more technicalities:

  • AT91SAM9263 is an ARM9-based system-on-a-chip with 200 million instructions per second, 27 DMA controllers, AC97 audio controller, USB 1.1 host,  compact flash, and more. See link for more info. A powerful little piece of hardware indeed; this means there could be literally anything in there.
  • U-Boot is a part of Linux4SAM, which led me to conclude they run Linux.
  • While they might, I doubt they run a GNU system. While it’s probably Linux, as it’s an embedded system I doubt it’s GNU; or at least GNU comprises a much smaller part of it than on desktops. Which is why in text above I’m calling the system just Linux and not GNU/Linux 🙂
This is all so fascinating. I hope someone does an interview with the designers of the system, and I’d love even more if I could meet those engineers. I’d love to hear some more inside info and some official specs. It’s quite sad that I’m basing all my info on system crashes.

Trams in Zagreb run (at least) X11

Raw unrotated cellphone pic, just taken.
These cool, touchscreen-enabled, smartcard-reading devices for ticket sales/verification seem to have only one flaw: a chunk of Engrish (‘select zone or aproach [sic] card’). They even run X11, probably on a UNIX! I suspect each device is just a dumb terminal that gets imagery over network, since other devices in the tram had proper (or improper, if switched to English) GUI displayed.