How do you launch an application in the X session of a user

Affaisseras · 2025-07-26 22:37:33

Suppose you've written a udev rule intended to launch Gnome Cheese (video recorder) when you plug in your webcam. The udev rule below isn't too hard to get down, standard stuff, in fact it's a tweaked example from the Arch Wiki.

KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", RUN+="/usr/bin/cheese"

But to ACTUALLY launch the application the command to run in your rule has to be this:

KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", RUN+="/usr/bin/systemd-run --machine=archie@ --user sh -c 'DISPLAY=:0 XAUTHORITY=$XDG_RUNTIME_DIR/Xauthority cheese'"

It does two things over just running /bin/cheese:
1. Runs it as your user
2. But it also needs to setup the DISPLAY and XAUTHORITY variables.

If simply running as your user were enough, we could just use /bin/sudo -u <user>, perhaps adding --login to the command for faithfulness. Setting up the correct enviroment variables accounts for most of the verbosity of the actual command!

The solution just doesn't feel elegant. Is there a better, more idiomatic way to launch applications like this? I'm certain I'm not the only one having this problem.

Some have created scripts to solve a similar problem, scripts which work essentially by snooping in the kernel's /proc interface about the enviroment of the Xorg process to obtain the XAUTHORITY enviroment variable. I'm wondering if there's a more idiomatic way to do this than what I've shown here.

Last edited by Affaisseras (2025-07-26 22:40:48)

seth · 2025-07-26 23:20:10

You don't want to run cheese etc from udev this way anyway: https://wiki.archlinux.org/title/Udev#S … _processes
You could kill two birds w/ one stone and use a script that takes a command and a username, looks up GUI processes of that user, inherits the relevant variables from there and then forks off and disowns the command to be able to quickly terminate.

KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SUBSYSTEMS=="usb", ATTRS{idVendor}=="05a9", ATTRS{idProduct}=="4519", RUN+="/usr/bin/xrunas archie cheese"

Affaisseras · 2025-07-27 10:02:26

Yeah, the example using sudo would block udev, systemd-run seems fine as it creates and runs a temporary unit.

A script that takes a command and a username, looks up GUI processes of that user, inherits the relevant variables from there and then forks off and disowns the command

I could code a program like this (xrunas would be a good name), but I'm looking to learn the 'standard' way to achieve the goal.

seth · 2025-07-27 10:49:30

There is no "standard way", you're trying to run a command in a different context of which you don't even know whether and how many of them exist.
Then you'll have to know what you need from there.
Then inherit it.

Even ifff

systemd-run --uid=1000 --slice user-1000.slice  xterm

would pick up some environment, you could still run multiple display servers out of the same session (xwayland problem)
You'll /have/ to be explicit in what context to run the process.

Affaisseras · 2025-07-27 11:18:13

seth wrote:

There is no "standard way", you're trying to run a command in a different context of which you don't even know whether and how many of them exist.

1. Whether the X session exists is not a concern. If there's no graphical session graphical programs won't launch, this is expected.
2. More than one X session running at the same time is uncommon, unless you're on Wayland. I know my devices.

Last edited by Affaisseras (2025-07-27 11:18:43)

seth · 2025-07-27 11:40:20

I'm looking to learn the 'standard' way to achieve the goal.

not a [subjective] concern … uncommon … I know my devices

Affaisseras · 2025-07-27 12:02:33

seth wrote:

I'm looking to learn the 'standard' way to achieve the goal.
not a [subjective] concern … uncommon … I know my devices

I 'quoted' the word for a reason, lol. And again multiple X processes are uncommon, this is a fact. A hypothetical xrunas program out there could just use the first X session available, and could also have option flags for precisely selecting a session, if needed.

You said such a tool can't exist because other heuristics/those extra options would be needed for some uncommon setups. This logic implies that a piece of software can't exist that serves two people with similar but slightly different needs.

seth · 2025-07-27 12:36:26

You said such a tool can't exist because other heuristics/those extra options would be needed for some uncommon setups.

No. But this is the problem. You're projecting.

You're asking for a standard approach which means for a generic solution.
But that makes assumptions about a generically solvable problem.
You're projecting your situation and preferences and make implicit assumptions, but in reality you're addressing a specific, contextual problem.
That specific problem has existed in various forms, long before udev, when people wanted to run GUI or IPC relevant tasks or anything depending on a specific environment from cronjobs and the specific solution to that specific problem is so trivial (set or import the relevant environment for your situation) that nobody has ever felt the need to write a complex program around it.
Because "could just use the first X session available, and could also have option flags for precisely selecting a session" isn't any different from that trivial solution…

Affaisseras · 2025-07-27 13:49:02

seth wrote:

That specific problem has existed in various forms, long before udev, when people wanted to run GUI or IPC relevant tasks or anything depending on a specific environment from cronjobs and the specific solution to that specific problem is so trivial (set or import the relevant environment for your situation) that nobody has ever felt the need to write a complex program around it.

I was strongly after what are the solutions that people have used. Do they just independently write a script that imports the environment from the Xorg process, like the script I've linked in the initial post? Setting the value of the XAUTHORITY variable by guessing is inviable, as the user could have always set it to somewhere else, frequently from their home directory to the non-default XDG_RUNTIME_DIR.

So, importing the environment from the Xorg process is something you have to do, have people re-invented that aforementioned script over and over?

Right now I'm also reading Running GUI applications as root wiki page, to glean some insight although it's not really what I'm looking for.

V1del · 2025-07-27 14:57:54

Why reinvent aforementioned script? You found it, so it exists so use it. One could try to find some Arch maintainer to package it if that would make it feel more "official", but yes that is generally the approach to take.

seth · 2025-07-27 15:17:22

The most commonly used approach is, if we're being honest, likely to hardcode the required enviroment.
nb. that AladW's script also makes assumptions (notably it fetches the environment from the xinit process - you might have to adjust that to use a guaranteed X11 process on your system)
It also does not import eg. DBUS_SESSION_BUS_ADDRESS which can be (only, eg. for notify-send) relevant.

Getting more generic, you'd probably have to scan through all processes of the user and look for conflict-free variables in order to automatically pick one.
(Ie. it's ok if the user doesn't have eg. DISPLAY on several of their processes, but if it's there, it has to be always the same to assume that it's the desired one)

as the user could have always set it to somewhere else

Worse: SDDM sets it to a randomized location.

Affaisseras · 2025-07-27 16:55:21

seth wrote:

Getting more generic, you'd probably have to scan through all processes of the user and look for conflict-free variables in order to automatically pick one.
(Ie. it's ok if the user doesn't have eg. DISPLAY on several of their processes, but if it's there, it has to be always the same to assume that it's the desired one)

I'm curious what you mean by this. If you're referring to a multi-display setup why not just look for the Xorg processes? (e.g. pgrep -u archie Xorg) That should give you the displays currently running on the system, i.e. :0, :1, etc. Commonly just :0.

Last edited by Affaisseras (2025-07-27 16:56:23)

seth · 2025-07-27 17:13:10

If one user has multiple processes with different relevant environment variables, the situation would become ambiguous and you cannot just guess.
The Xorg process doesn't necessarily run w/ user permissions, https://wiki.archlinux.org/title/Xorg#Rootless_Xorg
On top of that, there might be a multiscreen setup w/ :0.0 and :0.1 - https://wiki.archlinux.org/title/Multih … te_screens

Affaisseras · 2025-07-27 17:26:52

seth wrote:

If one user has multiple processes with different relevant environment variables, the situation would become ambiguous and you cannot just guess.
...
On top of that, there might be a multiscreen setup w/ :0.0 and :0.1 - https://wiki.archlinux.org/title/Multih … te_screens

What are the relevant environment variables that aren't present in the top Xorg processes?

seth · 2025-07-27 17:53:46

You're completely missing the point.

1. "the top Xorg processes" might be completely undetectable for running under a different UID, so you cannot infer from those whether they're relevant to the target user at all.
2. more than one DISPLAY can belong to the same X11 process
3. the user might be attached to multiple X11 servers (even remote ones) or dbus sessions (and that only concerns some GUI processes, that if you care about the tmux server, an ssh session, the gpg agent, the …whatnot)

You're turning your setup, single user, single X11 server, single dbus user session (hopefully, see the last link below), UID 1000, rootless server, … into "this is the only thing I need to care about" but then you can just hardcode the environment anyway.
That's the point I'm trying to make the entire time - there's no "standard way" because things can get WAY more complicated and ambiguous than *your* system - making it impossible to determine the "correct" environment.

Arch Linux

#1 2025-07-26 22:37:33

How do you launch an application in the X session of a user

#2 2025-07-26 23:20:10

Re: How do you launch an application in the X session of a user

#3 2025-07-27 10:02:26

Re: How do you launch an application in the X session of a user

#4 2025-07-27 10:49:30

Re: How do you launch an application in the X session of a user

#5 2025-07-27 11:18:13

Re: How do you launch an application in the X session of a user

#6 2025-07-27 11:40:20

Re: How do you launch an application in the X session of a user

#7 2025-07-27 12:02:33

Re: How do you launch an application in the X session of a user

#8 2025-07-27 12:36:26

Re: How do you launch an application in the X session of a user

#9 2025-07-27 13:49:02

Re: How do you launch an application in the X session of a user

#10 2025-07-27 14:57:54

Re: How do you launch an application in the X session of a user

#11 2025-07-27 15:17:22

Re: How do you launch an application in the X session of a user

#12 2025-07-27 16:55:21

Re: How do you launch an application in the X session of a user

#13 2025-07-27 17:13:10

Re: How do you launch an application in the X session of a user

#14 2025-07-27 17:26:52

Re: How do you launch an application in the X session of a user

#15 2025-07-27 17:53:46

Re: How do you launch an application in the X session of a user

Board footer