[bug#65343] [PATCH] home: services: Add 'x11-display' service.

[Andrew Tropin <andrew@trop.in>]

[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]

On 2023-08-16 16:55, Brian Cully wrote:

> The largest issue I see with this patch is that it doesn't correlate the
> X11 socket with the session being used in cases where there's more than
> one X11 display.
>
> If, for instance, I start an X session on the console, allocating the
> first display (:0), everything will start up correctly. If I then log in
> from a remote host with SSH using X forwarding, I'll get another display
> allocated (:1), but this isn't accounted for. If I do these operations
> in reverse, first starting my X-forwarded SSH session, then logging in
> via console, it will almost certainly not do what just about anyone
> wants.
>
> This does presume the Shepherd can be started multiple times for a given
> user, and run concurrently, though this does not appear to actually be
> the case, since there's a single global location for the socket, which
> isn't differentiated by session. But that's a separate issue.
>
> This also doesn't handle the case of the X11 server going away, either
> by crash or user request. If we're starting stuff on behalf of users
> when it comes up, it seems to me we should also be stopping stuff on
> users' behalf when it comes down. The lack of handling this could easily
> lead to resource-churning loops where X11 goes away, but Shepherd
> services continuously restart themselves trying to connect to a display
> that no longer exists.
>
> If this is only meant to be used when using a display manager, a la gdm,
> then it might be ok. I'm not sure, since I don't use them. When logging
> out of an X session started from gdm, is the user's shepherd process
> stopped? Is it stopped gracefully? What about sddm? lightdm?

I have been seeking for the solution for this for some time and also
tried similiar thing as Ludo's patch does and I'm agree with concerns
mentioned above by Brian.

At the end in rde we decided to start shepherd by Sway (wayland
compositor), so all the services have proper environment variables.  It
has other downsides, but overall works well for usual desktop use cases.

I don't have a complete generic answer to this problem yet.

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]