See also #23834

@joachifm what do you think is wrong with this solution?

It doesn't address the actual problem, as I see it.

@joachifm what is the actual problem? that display is null?

User services that rely on graphical.target are fundamentally broken, the dependency makes no sense. If it worked properly, DISPLAY would be set at the time the service is activated.

@bennofs I think #17858 (comment) is the proper solution.

@joachifm hmm. but you'd also have to import-env DISPLAY into the systemd user instance, right (as the systemd user instance does not expose DISPLAY to services by default afaik)? Also, isn't there only one systemd user instance for all sessions if a single user? What happens if a user is logged into multiple graphical terminals?

Perhaps we should merge this in the mean time, and remove it again when we figure out a proper solution. I don't think that this will hurt too much, no?

My primary objection is about correctness, not pragmatics, so please go ahead. I don't use these servies, so have no real stake in them.

I'll just note that I think graphical-session is the real fix for user services that are part of a graphical session &c. Hard-coding DISPLAY to 0 only works because it's what DISPLAY tends to be in practice, but that's incredibly fragile. IMO graphical user services are currently completely shoehorned in and should have been implemented by adding stuff to xinitrc/xsession to begin with ... But here we are :)

To clarify, the main problem is using dependencies and ordering in these cases, as they are inherently nonsensical and so require kludges like this. You could for example activate the unit manually in xinitrc, to make use of systemd for supervision & whatnot, I see nothing wrong with that.

Ok then I will merge this for now. We already have an issue for improving the general situation.