[systemd-devel] Standardizing names for graphical session units
Zbigniew Jędrzejewski-Szmek
zbyszek at in.waw.pl
Mon Jul 4 22:20:41 UTC 2016
On Mon, Jul 04, 2016 at 10:01:48PM +0200, Martin Pitt wrote:
> Hello all,
>
> a while ago I started experimenting with converting Ubuntu's upstart
> graphical session to the user D-Bus and systemd session. This works
> nicely and naturally for services which don't need $DISPLAY and are
> not session specific, like pulseaudio or gvfs. However, others like
> nautilus, mutter, unity etc. are absolutely specific to the
> graphical session, so they need some shims to bind starting/stopping
> them to the lifetime of the graphical session instead of the user. I
> started a small discussion here in May [1].
>
> I now have a prototype [2] which converts about half of the graphical
> session to systemd units. We'll have a mini-sprint later in July to
> complete/formalize this, but I'd like to settle some ground work
> before. I don't think it makes much sense if every distro or project
> comes up with their own naming schema and approach for this, as this
> would again mean to introduce pointless diversion -- and one of
> systemd's goals is to reduce these between distros -- and consequently
> the inability to send/maintain these session service units upstream.
> So let's see whether we can reach some agreement and recommendation
> here and ship that upstream?
>
> One proposed home-grown solution [3] is to introduce an
> X11@${_DISPLAY}.target, but this isn't ideal: We shouldn't use "X11"
> when Wayland/Mir become increasingly popular, and this is too
> inflexible wrt. having multiple session types, such as "GNOME", "KDE",
> "Unity", or "i3": Some services may want to start in all or several of
> those (e. g. gnome-settings-daemon is useful in an Xfce or i3
> session), some others like gnome-shell are only being used in the
> "GNOME" session.
>
> There's two separate issues here, a "container" unit for the session
> services and how to start/stop them with the session.
>
> Container unit(s)
> -----------------
> All services/programs that should start in a particular graphical
> session like "GNOME" or "Xfce" should be "bundled" by some wrapper
> unit, so that they can be shut down as a group when the session ends.
> target units would be the immediate natural choice, but are not
> actually that suitable:
>
> * Stopping a target doesn't (by default) stop its requirements
> (but maybe I'm just missing something here).
Hi Martin,
I don't think we should "misuse" slices for this. Slices are for
resource management, and reusing them for unit grouping will be
confusing for users. Also, using slices for this ties the target
hierarchy to the resource hierarchy.
I think we should instead enhance target units to provide missing
functionality. The most important thing would be to have something
like PartOf, but more nicely configured. PartOf=graphical-kde.target
would do the trick, but it would need to be configured in each
unit separately, which would mean that we'd need to duplicate each
unit for each target, which is unacceptable. I don't see a nice
way to achieve this with the current set of options. What about
adding DependenciesPartOf=yes|no on the target unit, with "yes"
meaning that we automatically add PartOf= dependencies to any service
which has a Wants= or Requires= dependency to the target.
> * You have to pre-define them, so we would need to have on-disk
> units for all session types like graphical-xfce.target,
> graphical-gnome.target, etc.
I don't think this is such a big problem. After all it's going to be
a few (3? 5?) units, and a file is needed to provide Description=
and Documentation= anyway.
I have to agree with Jóhann that "graphical-" part does not seem necessary.
I'd rather go for "kde-session.target", "gnome-session.target", etc.
And I don't think that the requirement for a unit file is a hurdle
for step-wise conversion. Once you want to convert, let's say, xfce,
you create xfce-session.target with some Description, and start linking
units to it through .wants or .requires dirs, and that's totally
independent of any other session.
Zbyszek
More information about the systemd-devel
mailing list