Apparently (at least on some distros), using sudo does not trigger the pam_systemd module. This causes issues with software that relies on D-Bus and other session services (e.g. dconf).
It seems that most applications are fine with this, but some functionality may be broken.
An alternative would be to use ssh or "machinectl shell" (https://unix.stackexchange.com/questions/346841/why-does-sudo-i-not-set-xdg-runtime-dir-for-the-target-user)
The downside is that these lack simple configuration for paswordless use.
That also opens a new can of worms: Gnome applications will hang for some seconds on startup because they expect xdg-desktop-portal-gtk, which fails to start, presumably because env vars haven't been injected at that point.
xdg-desktop-portal-gtk[524663]: Unable to init server: Could not connect: Connection refused
xdg-desktop-por[524663]: cannot open display:
Running /usr/lib/xdg-desktop-portal-gtk manually from the shell solves that issue.
Apparently (at least on some distros), using
sudodoes not trigger the pam_systemd module. This causes issues with software that relies on D-Bus and other session services (e.g. dconf).It seems that most applications are fine with this, but some functionality may be broken.
An alternative would be to use ssh or "machinectl shell" (https://unix.stackexchange.com/questions/346841/why-does-sudo-i-not-set-xdg-runtime-dir-for-the-target-user)
The downside is that these lack simple configuration for paswordless use.
That also opens a new can of worms: Gnome applications will hang for some seconds on startup because they expect
xdg-desktop-portal-gtk, which fails to start, presumably because env vars haven't been injected at that point.Running
/usr/lib/xdg-desktop-portal-gtkmanually from the shell solves that issue.