[SOLVED] Launch wayland compositor without having to manually set XDG_RUNTIME_DIR envvar

Hi there,

Wayland compositors (at least the ones based on wlroors) use libseat, which in turn uses information set by systemd-logind, so the user doesn’t have to manually set the XDG_RUNTIME_DIR envvar to launch a wayland compositor.

So in DietPi, I went and unmasked systemd-logind, and installed dbus (I don’t like’em, but, well…)

systemd-logind is now running well:


root@DietPi:~# systemctl status systemd-logind
● systemd-logind.service - User Login Management
     Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)
     Active: active (running) since Wed 2023-04-19 16:29:25 BST; 1min 54s ago
       Docs: man:sd-login(3)
             man:systemd-logind.service(8)
             man:logind.conf(5)
             man:org.freedesktop.login1(5)
   Main PID: 422 (systemd-logind)
     Status: "Processing requests..."
      Tasks: 1 (limit: 9203)
     Memory: 1.3M
        CPU: 61ms
     CGroup: /system.slice/systemd-logind.service
             └─422 /lib/systemd/systemd-logind

But when launching a Wayland compositor, it can’t find the XDG_RUNTIME_DIR information:


root@DietPi:~# labwc
00:00:00.000 [../src/config/rcxml.c:899] cannot read (/rc.xml)
00:00:00.000 [../src/main.c:157] XDG_RUNTIME_DIR is unset

Any idea what’s the missing piece here, please?
I am OK-ish with manually exporting the envvar, but I’d like to understand…

Maybe you could ask your question on GitHub - labwc/labwc: A Wayland window-stacking compositor

Probably they know what might be missing.

The problem is that I already have labwc working on other systems (x86_64 laptop, Pi4…) and I only had to worry about systemd-logind being active, so there must be something specifically different with DietPi…

But well, I will ask there anyway.

EDIT: The more I think about it, the more I get the impression that having systemd-logind active should do this for me, and the fact that it doesn’t means that something else is missing in DietPi.

Ok, solved this. The missing piece was libpam-systemd, which also had to be installed.

This was a DietPi problem in the end, and not the first time that it bites someone in the ass:

So, even if your intentions were good, please don’t send people to ask elsewhere when it’s clearly a distro-specific problem: that does not help anybody.

Thanks!

This could be the case. Our goal is to create images with as few installed packages as possible. This means that we only deliver a pure image and additional software must be installed if needed. This is not a problem but works as designed.