sd_pid_get_user_unit started returning incorrect values in systemd v259-rc2

[NTMan]

What happened

Starting with v259-rc2 (and the current main branch), the XWayland server no longer receives the Xft.dpi (and related) resources that were previously populated by udev.

As a result, every single X11/XWayland application renders at exactly 96 dpi / 100% scale on HiDPI displays, regardless of the compositor scaling settings (200%, 150%, etc.).

This instantly breaks Steam, Discord, Zoom, Slack, VS Code, all JetBrains tools, Firefox (when not forced to Wayland), Wine, Electron apps, etc. on all Wayland compositors that use rootful or rootless XWayland (GNOME/Mutter, KDE/KWin, sway/wlroots-based, Hyprland, etc.).

Hard evidence

systemd v258.2-1 (working, 200% scaling):

$ xrdb -query | grep Xft.dpi
Xft.dpi: 192

systemd v259-rc2 (broken):

$ xrdb -query | grep Xft.dpi
<no output — the resource is completely missing>

Regression window

• systemd v258 → works perfectly
• systemd v259-rc2 → completely broken

Reproduction (minimal)

1. Any Linux distribution with systemd v259-rc2 or newer (e.g., Fedora Rawhide)
2. Wayland session (GNOME, KDE, sway, anything)
3. Set display scaling ≠ 100% in the compositor
4. Launch Steam or any X11 application
5. Run xrdb -query | grep Xft.dpi → empty

Environment

• Distribution: Fedora Rawhide (as of November 30, 2025)
• Compositor: GNOME on Wayland
• Display: HiDPI (e.g., 3840×2160)
• Kernel: 6.18-rc7
• Hardware: x86_64

Workarounds (temporary)

• Downgrade systemd to v258

Downstream report

https://bugzilla.redhat.com/show_bug.cgi?id=2417768

[arvidjaar]

hwdb/90-x11-monitor-dpi.hwdb src/basic/x11-util.c

Neither of these files existed in the version 258.

[poettering]

Sorry, but systemd upstream never has set "Xft.dpi" or anything like that. That must be some oter package or downstream change, but we are really not involved at all in dpi managing of the graphics stack.

Please report this downstream and ping the xwayland devs about this, but not us here in systemd, we are really not involved.

[bluca]

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8866

[AdrianVovk]

This is a systemd bug, by the looks of it. sd_pid_get_user_unit seems to be returning system unit names

Here's a test program for sd_pid_get_user_unit:

#include <stdio.h>
#include <stdlib.h>
#include <systemd/sd-login.h>

void main(int argc, char *argv[]) {
	char *unit = NULL;
	int r;

	r = sd_pid_get_user_unit(atoi(argv[1]), &unit);
	if (r < 0) {
		errno = -r;
		printf("Error: %m\n");
		return;
	}

	printf("Unit: %s\n", unit);
}

On my system, when I compile and run this I get:

$ gcc $(pkgconf --libs libsystemd) foo.c -o foo
$ ./foo `pidof gnome-shell`
Unit: user@1000.service

Returning the wrong unit name tricks gnome-shell into thinking that this is a non-systemd system. Since it's a non-systemd system, we never ask systemd to start gnome-session-x11-services-ready.target, and without that target running we don't have gnome-settings-daemon-xsettings running, and without g-s-d-xsettings there's nothing to tell X11 clients the correct settings (i.e. dpi)

[AdrianVovk]

The two likeliest culprits are (in order, from my quick skim of the changes):

• Drop remaining CGroup v1 specific code #38969
• cgroup-util: add pidref+full counter parts for cg_pid_get_user_unit() #39103