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

* gnu/home/services/desktop.scm (x11-shepherd-service): New procedure.
(home-x11-service-type): New variable.
(redshift-shepherd-service): Add 'requirement' field.
(home-redshift-service-type): Extend 'home-x11-service-type'.
* doc/guix.texi (Desktop Home Services): Document it.
---
 doc/guix.texi                 | 22 ++++++++++
 gnu/home/services/desktop.scm | 82 ++++++++++++++++++++++++++++++++---
 2 files changed, 99 insertions(+), 5 deletions(-)

Hello Guix!

This is an attempt to fix a longstanding issue with Home services
that depend on X11: how can we make sure that (1) they are not started
when X is not running, and (2) they get the correct ‘DISPLAY’
variable.

It’s a bit of a hack (the idea came up during a discussion on IRC
a few days ago), but it does the job.  I guess it could be
extended to Wayland as well, but I’m not familiar with it.

Thoughts?

Ludo’.


base-commit: 880ada0bdb9e694573ec42200d48658b27744b9b

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> * gnu/home/services/desktop.scm (x11-shepherd-service): New procedure.
> (home-x11-service-type): New variable.
> (redshift-shepherd-service): Add 'requirement' field.
> (home-redshift-service-type): Extend 'home-x11-service-type'.
> * doc/guix.texi (Desktop Home Services): Document it.
> ---
>  doc/guix.texi                 | 22 ++++++++++
>  gnu/home/services/desktop.scm | 82 ++++++++++++++++++++++++++++++++---
>  2 files changed, 99 insertions(+), 5 deletions(-)
>
> This is an attempt to fix a longstanding issue with Home services
> that depend on X11: how can we make sure that (1) they are not started
> when X is not running, and (2) they get the correct ‘DISPLAY’
> variable.
>
> […]
>
> Thoughts?

If I understood the patch correctly, the ‘x11-shepherd-service’
procedure finds a first file like ‘/tmp/.X11-unix/X0’ or
‘/tmp/.X11-unix/X2’ which is readable by a user which runs the Shepherd.

Is it possible to allow a user to exactly specify a list of files in
‘/tmp/.X11-unix’ directory, which will be checked?  It will be useful
for VNC users to make sure X11 services are running on a specified
DISPLAY. Otherwise X11 services will be running on a DISPLAY handled by
VNC after boot and never on DISPLAY which becomes available after
authentication (XWayland, GDM , SLIM, LightDM, etc).

Regards,
Oleg.

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?

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.

Hello Brian & Oleg,

Brian Cully <bjc@spork.org> skribis:

> 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.

Yeah, and similarly with the scenario Oleg describes.

> This does presume the Shepherd can be started multiple times for a given
> user,

No no, but it assumes simple scenarios: when you first login locally, X
is not running yet, but you eventually start it and that’s the display
you want your services to use.  Anything beyond that won’t work, as you
point out.

A simple improvement would be to stop the service when the relevant
/tmp/.X11-unix socket disappears.

As for which display to use when several are available (the SSH example
above), I don’t know.  Apparently elogind doesn’t know which display
corresponds to a “seat”.  Maybe we shouldn’t try to guess and instead
let users specify it, for instance with ‘herd start x11-display :42’?

Now, without this service the situation is even worse: shepherd and its
sub-processes inherit whatever ‘DISPLAY’ value was in its environment,
if any, and that’s it.  This service is a hack, but might still do more
good than harm?

Ludo’.

Ludovic Courtès <ludo@gnu.org> writes:

[…]

> Now, without this service the situation is even worse: shepherd and its
> sub-processes inherit whatever ‘DISPLAY’ value was in its environment,
> if any, and that’s it.  This service is a hack, but might still do more
> good than harm?

Inheriting environment variable is under the user's controll. Finding a
readable file by the user is less (requires to start x11 sessions in a
specific order). By more controll I mean the user could stop Shepherd on
a DISPLAY :0 and start it on DISPLAY :1 without stopping x11 sessions.

In any case, current patch with or without specification of files order
(or ‘herd start x11-display :42’) will change current behaviour. So, I
think a small entry in ‘news.scm’ could save somebody a day.


Regards,
Oleg.