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

[Brian Cully]

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?