Re: [systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Andrei Borzenkov [2016-07-07 11:39 +0300]:
> Do not we already have "session" concept in logind? Is not session
> already stopped when user logs out?

Yes, but user systemd units don't "see" the system logind scopes, so
you can't relate to them. And the user systemd instance continues to
run after you log out of the graphical session, as long as that user
still has some other (non-graphical) session open.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Andrei Borzenkov]

On Thu, Jul 7, 2016 at 11:27 AM, Martin Pitt  wrote:
> Zbigniew Jędrzejewski-Szmek [2016-07-04 22:20 +]:
>> 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.
>
> This would still not be sufficient, AFAICS. The top-level targets will
> only have relatively few direct dependencies. Let's suppose
> gnome-session.target has
> "Requires=mutter.service gnome-settings-daemon.service"
> and mutter.service then has a "Wants=at-spi2.service". We still want
> to stop at-spi2.service together with the session.
>
> DependenciesPartOf=yes in gnome.target would not achieve that (or it
> would need to apply transitively, and to Wants= as well, which sounds
> quite strange). OTOH adding "PartOf=graphical-session.target" to all
> graphical session specific user services works fine and works with the
> existing systemd model and dependencies.
>


Do not we already have "session" concept in logind? Is not session
already stopped when user logs out?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Zbigniew Jędrzejewski-Szmek [2016-07-04 22:20 +]:
> 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.

This would still not be sufficient, AFAICS. The top-level targets will
only have relatively few direct dependencies. Let's suppose
gnome-session.target has
"Requires=mutter.service gnome-settings-daemon.service"
and mutter.service then has a "Wants=at-spi2.service". We still want
to stop at-spi2.service together with the session.

DependenciesPartOf=yes in gnome.target would not achieve that (or it
would need to apply transitively, and to Wants= as well, which sounds
quite strange). OTOH adding "PartOf=graphical-session.target" to all
graphical session specific user services works fine and works with the
existing systemd model and dependencies.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Martin Pitt [2016-07-07  9:29 +0200]:
> I'll go ahead and create a PR with the unit and a manpage, using
> graphical-session.target for now. Then the name bikeshedding can be
> continued there.

https://github.com/systemd/systemd/pull/3678

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Hello Jóhann,

Jóhann B. Guðmundsson [2016-07-06 16:22 +]:
> It's more about people will be have hard time distinguish between two or
> more type units with the same name but serve two different purposes.

I was thinking graphical.target would be nicely symmetrical to the
system-level one, but there's the confusion potential, yes. So if we
call the "real" sessions like gnome-session.target, then IMHO that
generic "alias" target should have the same form;
graphical-session.target would be reasonable.

> One way to solve them is with type target units as you proposed (
> user-graphical.target could serve that purpose ) but back in the day Lennart
> was against introducing generic type targets like webserver.target,
> database.target etc

Oh, I wasn't aware of this. I guess we'll let him have the last word
about that then? :-)

I'll go ahead and create a PR with the unit and a manpage, using
graphical-session.target for now. Then the name bikeshedding can be
continued there.

BTW, I updated http://people.canonical.com/~pitti/tmp/session.sh to
have a kde.target as well, to demonstrate that this works with two
independent sessions.

Thanks everyone for their input!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Jóhann B . Guðmundsson]

># gnome-user-graphical.target
>
>[Unit]
>Description=User systemd services for graphical session
>StopWhenUnneeded=yes

So this is just another name for "my"
gnome.target/gnome-session.target. As I said I'm not too fussed about
how we name those, we should just decide about some convention.


Right.




>In your script you had an conflicting naming scheme (
>gnome.target/graphical.target ) and a colliding one ( graphical.target with
>systemd default and potentially other DE's as well ) if multiple desktop
>environments where installed.

I don't see a conflict. These are all per-user units, so if user A
runs kde-session.target and user B runs gnome-session.target that's
fine -- the two user systemd instances don't even know about each
other.


It's more about people will be have hard time distinguish between two or 
more type units with the same name but serve two different purposes.


This would work if an new type unit would be introduced which could be 
called .session or .user so you would end up with gnome.session or 
gnome.user instead of gnome.target for example or gnome.service etc.


It might be an option to introduce a new type unit(s) since the existing 
type units might not be the right way to handle this.



>And you also might need to add something like an Alias ( like for example
>"Alias=user-graphical.target" ) directive to the DE-user-graphical.target
>unit so that someapp.service can be made PartOf an generic directive
>(PartOf=user-graphical.target) to make it DE agnostic ( should it be
>required to be so ) if it's not DE specific. ( if you follow me here ).

I do follow. However, there is no such thing as a "runtime alias" for
units, TTBOMK. There is Alias= in the [Install] section, but this
cannot really be used for this purpose -- we don't want to change
the /usr/lib/systemd/user/user-graphical.target symlink every time
that we start a user session in a DM.


I was just using it as an example since you have the same problem trying 
to describe "generic" ordering/requirement/dependency in type units.


One way to solve them is with type target units as you proposed ( 
user-graphical.target could serve that purpose ) but back in the day 
Lennart was against introducing generic type targets like 
webserver.target, database.target etc which would have simplified things 
quite a bit in various type service for applications that needed for 
example be ordered either after or before like After=webserver.target vs 
having to define all of them in the existence 
Apache,Nginx,Lighttpd,Monkey,Cherokee,Hiawatha etc. So I just 
automatically dismissed that as a solution since I assumed he would be 
consistent and reject such proposals/ideas.


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Hello Jóhann,

Jóhann B. Guðmundsson [2016-07-06 15:23 +]:
> What I'm ( poorly ) trying to say is that you will need to make a clear
> distinction of naming on the type units for the desktop environment and the
> type units for the desktop environment user

I don't understand the distinction between these two.

> and potentially other existing type units on the system to avoid
> confusions and conflicting naming scheme,

system and user units are completely unrelated to each other. Of
course naming them poorly could cause some confusion. This was the
main reason for proposing some sort of prefix or suffix, like
graphical-$SESSION.target or $SESSION-session.target or so. This does
not need to be firmly defined, and systemd itself does not need to
know about it, but it might still be useful to give a recommendation
so that the various desktop sessions have some naming consistency.

> since Desktop Environments will need to have their own targets so based on
> my comments on this and for Gnome ( on Fedora ) and on the type units you
> are creating in your script ( that all have to reside in
> ~/.config/systemd/user/ directory for all the desktop environment user type
> units right )

I just used ~/.config/systemd/user/ for my test script. Obviously
actual packages would ship them in /usr/lib/systemd/user/.

> so this would become something along the lines of
> 
> # gnome.target
> 
> [Unit]
> Description=Gnome Desktop Environment
> Documentation=https://wiki.gnome.org/
> Requires=multi-user.target
> Wants=gdm.service
> Conflicts=rescue.service rescue.target
> After=multi-user.target rescue.service rescue.target gdm.service
> AllowIsolate=yes

I still think you are confusing user and system units here.
*Everything* in this thread (like gnome.target) is about *user*
systemd units. The above are all system units -- the user instance
does not know about gdm, rescue.service, etc. So this unit wouldn't
work at all.

Or asked the other way around, why do you need a gnome.target on the
system side? There might very well be reasons why you want to split
the system graphical.target into DE specific ones, to make it easier
to start the correct DM. However, this is unrelated to how to start
stuff *in* the graphical session.

> # gnome-user-graphical.target
> 
> [Unit]
> Description=User systemd services for graphical session
> StopWhenUnneeded=yes

So this is just another name for "my"
gnome.target/gnome-session.target. As I said I'm not too fussed about
how we name those, we should just decide about some convention.

> In your script you had an conflicting naming scheme (
> gnome.target/graphical.target ) and a colliding one ( graphical.target with
> systemd default and potentially other DE's as well ) if multiple desktop
> environments where installed.

I don't see a conflict. These are all per-user units, so if user A
runs kde-session.target and user B runs gnome-session.target that's
fine -- the two user systemd instances don't even know about each
other.

> And you also might need to add something like an Alias ( like for example
> "Alias=user-graphical.target" ) directive to the DE-user-graphical.target
> unit so that someapp.service can be made PartOf an generic directive
> (PartOf=user-graphical.target) to make it DE agnostic ( should it be
> required to be so ) if it's not DE specific. ( if you follow me here ).

I do follow. However, there is no such thing as a "runtime alias" for
units, TTBOMK. There is Alias= in the [Install] section, but this
cannot really be used for this purpose -- we don't want to change
the /usr/lib/systemd/user/user-graphical.target symlink every time
that we start a user session in a DM.

Hence my idea of a graphical.target user unit which would act like an
alias, as it starts and stops together with whatever-session.target.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Jóhann B . Guðmundsson]

On 07/06/2016 02:34 PM, Martin Pitt wrote:


This /usr/lib/systemd/user/graphical.target (and only that)*does*
belong in to systemd, as it cannot sensibly be in any
gnome-session/mate-session/kde-session/etc. package -- it's a shared
resource/synchronization point between all of those. Having a unit
structure which actually works and is reasonably easy to extend and
maintain is AFAICS the main blocker why systemd isn't being used for
desktop environments at all yet.


I think we are talking somewhat in mixed direction here.

What I'm ( poorly ) trying to say is that you will need to make a clear 
distinction of naming on the type units for the desktop environment and 
the type units for the desktop environment user and potentially other 
existing type units on the system to avoid confusions and conflicting 
naming scheme, since Desktop Environments will need to have their own 
targets so based on my comments on this and for Gnome ( on Fedora ) and 
on the type units you are creating in your script ( that all have to 
reside in ~/.config/systemd/user/ directory for all the desktop 
environment user type units right ) so this would become something along 
the lines of


# gnome.target

[Unit]
Description=Gnome Desktop Environment
Documentation=https://wiki.gnome.org/
Requires=multi-user.target
Wants=gdm.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target gdm.service
AllowIsolate=yes

# gdm.service

[Unit]
Description=GNOME Display Manager
Conflicts=getty@tty1.service
After=getty@tty1.service
Conflicts=plymouth-quit.service
After=plymouth-quit.service
After=rc-local.service plymouth-start.service systemd-user-sessions.service
OnFailure=plymouth-quit.service

[Service]
ExecStart=/usr/sbin/gdm
KillMode=mixed
Restart=always
IgnoreSIGPIPE=no
BusName=org.gnome.DisplayManager
StandardOutput=syslog
StandardError=inherit
EnvironmentFile=-/etc/locale.conf

# gnome-user-graphical.target

[Unit]
Description=User systemd services for graphical session
StopWhenUnneeded=yes

# gnome-user.target
[Unit]
Description=User systemd services for GNOME graphical session
BindsTo=gnome-user-graphical.target  gnome-user-session.service

# gnome-user-session.service
[Unit]
Description=gnome-user-session leader
PartOf=gnome-user-graphical.target

[Service]
ExecStart=/bin/sleep infinity

# someapp.service
[Unit]
Description=example graphical app
PartOf=gnome-user-graphical.target

[Service]
ExecStart=/bin/sleep infinity

...

This will allow for

# DE units
kde.target
kdm.service
xfce.target
xdm.service


DE user type units
kdm-user-graphical.target
kdm-user.target
kdm-user-session.service
xfce-user-graphical.target
xfce-user.target
xfce-user-session.service
etc..

In your script you had an conflicting naming scheme ( 
gnome.target/graphical.target ) and a colliding one ( graphical.target 
with systemd default and potentially other DE's as well ) if multiple 
desktop environments where installed.


And you also might need to add something like an Alias ( like for 
example "Alias=user-graphical.target" ) directive to the 
DE-user-graphical.target unit so that someapp.service can be made PartOf 
an generic directive (PartOf=user-graphical.target) to make it DE 
agnostic ( should it be required to be so ) if it's not DE specific. ( 
if you follow me here ).


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Jóhann B. Guðmundsson [2016-07-06 14:02 +]:
> Martin is proposing changes to and dependency's on the graphical.target

I'm not changing anything. graphical.target as it exists in systemd
today is for the *system* instance. I'm talking about the *user*
instance, which has no graphical.target at all right now. You could
also call it graphical-session.target.

> trying to make it act as the abstraction layer ( since there does not exist
> a single DM solution that serves all DE properly ) which will never work
> since each desktop environment will need it's own target which can be
> isolated to so applications/administrators and end users can switch desktop
> environments

Correct, every desktop environment will need its own target. This plus
the generic graphical.target are precisely for supporting multiple
parallel session types.

> If you only have a single DE environment installed you could just make that
> DE the default target of the installment and skip entirely the graphical
> target if everything gets correctly implemented

No, even that wouldn't work. default.target is also run for
non-graphical user sessions, such as ssh, VT, or even cron. These must
*not* try to start graphical stuff like gnome-session.

> however if you try to use a DM that belongs to an single desktop environment
> ( as opposed to one DM to rule them all ) with multiple desktop environments
> you will always end up with a mess on your hand.

This is all fairly unrelated to DMs really.

> In anycase none of the desktop environment targets should ever be shipped
> with systemd upstream and depend on graphical.target but only be as a part
> of their relevant desktop environment, shipped with it and depend on it's
> own target.

Correct, and that's what I proposed. But we need the graphical.target
so that we can sanely make graphical user services get stopped with
the graphical session without having to update them all the time.

This was explained in several other parts of the thread, but suppose
you have gnome-settings-daemon.service: With just "gnome.target" this
would need a "PartOf=gnome.target", so that stopping gnome.target also
stops gnome-settings-daemon.service.

Now suppose we add a mate.target for a MATE session, which also
happens to use g-s-d. We would now need to modify
gnome-settings-daemon.service to add "PartOf=mate.target", and do the
same to all other session services that are shared between multiple
desktop session types. This is a combinatorial explosion and pointless
update exercise. We can assume that we only have (at most) *one*
graphical session running (that's dbus-user-session's building
principle) and so we can insert this "graphical.target" in the middle
to mean "the current graphical session", so that
gnome-settings-daemon.service and friends only need
"PartOf=graphical.target" and they never need to be updated for
new session types.

This /usr/lib/systemd/user/graphical.target (and only that) *does*
belong in to systemd, as it cannot sensibly be in any
gnome-session/mate-session/kde-session/etc. package -- it's a shared
resource/synchronization point between all of those. Having a unit
structure which actually works and is reasonably easy to extend and
maintain is AFAICS the main blocker why systemd isn't being used for
desktop environments at all yet.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Jóhann B . Guðmundsson]

On 07/06/2016 12:51 PM, Jan Alexander Steffens wrote:
On Wed, Jul 6, 2016 at 2:21 PM Jóhann B. Guðmundsson 
> wrote:



It's questionable if such application should reside in upstream
systemd since arguably systemd should have never created the
graphical.target to begin with ( if it had not we probably would
not be having this discussion since desktop environment targets
would have been created instead ).



What do you mean? There is no user-level graphical.target in systemd 
(yet), and this discussion has nothing to do with the system-level 
graphical.target.


Martin is proposing changes to and dependency's on the graphical.target 
trying to make it act as the abstraction layer ( since there does not 
exist a single DM solution that serves all DE properly ) which will 
never work since each desktop environment will need it's own target 
which can be isolated to so applications/administrators and end users 
can switch desktop environments ( by simply switching/isolating to 
another target ) if they have installed multiple DEs to be able to 
effectively handle the usecase that Colin pointed out ( classic use case 
for that are labs in university's ) .


If you only have a single DE environment installed you could just make 
that DE the default target of the installment and skip entirely the 
graphical target if everything gets correctly implemented ( in effect 
obsoleted it ) however if you try to use a DM that belongs to an single 
desktop environment ( as opposed to one DM to rule them all ) with 
multiple desktop environments you will always end up with a mess on your 
hand.


In anycase none of the desktop environment targets should ever be 
shipped with systemd upstream and depend on graphical.target but only be 
as a part of their relevant desktop environment, shipped with it and 
depend on it's own target otherwise systemd as an core/baseOS component 
is being (mis)used to achieved consolidation in areas which are outside 
it's scope.


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Martin Pitt [2016-07-06 13:47 +0200]:
> Simon McVittie [2016-07-05 10:27 +0100]:
> > Could this be done by having the .desktop file in /usr/share/xsessions
> > or /usr/share/wayland-sessions start an appropriate systemd user unit
> > directly, and wait for it to terminate?
> 
> There is currently no command (other than a polling loop) to wait
> until a particular unit gets stopped. I.  e.
> 
>   Exec=gnome-session --session=gnome
> 
> would need to be replaced with something like
> 
>   Exec=/bin/sh -c "systemctl start gnome-session.target; 
> wait-until-service-stopped gnome-session.service; systemctl stop 
> gnome-session.target"

[...]

> I have a gut feeling that this should be expressible with systemd
> dependencies -- i. e. "if gnome-session.service stops, then stop
> gnome-session.target".

The v3 approach now does this, so the above would reduce to something
like

  Exec=/bin/sh -c 'systemctl start gnome-session.target; systemctl wait-unit 
gnome-session.target'

for a hypothetical "wait-unit" verb which blocks until the given unit
stops. Or perhaps even

  Exec=systemctl start --wait-until-stopped gnome-session.target

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Hello Jan,

Jan Alexander Steffens [2016-07-06 11:57 +]:
> Note that systemd makes a difference between "gnome-session.service became
> inactive" and "gnome-session.service gets stopped". A service terminating
> by itself is the former.
> 
> Requires= and PartOf= will only propagate the latter. BindsTo= also stops
> on the former (besides acting like Requires=).
> 
> So, if gnome-session.target BindsTo=gnome-session.service,
> gnome-session.target requires gnome-session.service and will be stopped
> when the service exits.
> 
> There's also StopWhenUnneeded=, which might useful on the targets.

Indeed. The version 3 approach now uses that, and this finally works
as intended. Thanks for pointing out!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units -- version 3, now working!

[Martin Pitt]

Andrei Borzenkov [2016-07-06 14:44 +0300]:
> On Wed, Jul 6, 2016 at 2:25 PM, Martin Pitt  wrote:
> >$ cat .config/systemd/user/gnome-session.target
> >[Unit]
> >Description=User systemd services for GNOME graphical session
> >Requires=graphical.target
> >PartOf=graphical.target
> >
> 
> Is not this redundant? Requires=graphical.target already stops
> gnome-session.target when graphical.target is stopped (by any mean).

Yes, but at the same time Requires= isn't strong enough, it needs
BindsTo=.

> > The only glitch is that "systemctl --user stop gnome-session.target"
> > only stops that target itself. I would have expected it to stop
> > graphical.target too (and someapp along with it), as it has
> > PartOf=graphical.target. This might be a bug in systemd, or some
> > semantics of PartOf with targets that I don't understand.
> 
> You probably do not understand. If foo.service is PartOf=bar.target,
> then stopping bar.target stops foo.service. State of foo.service
> itself has no impact of bar.target.

Indeed, thanks. This needs another BindsTo=.

I now created a script which sets up the units and exercises various
start/stop scenarios to ensure that we get the behaviour that we want.
This now introduces a (fake) gnome-session.service that we consider
the "session leader", and renames gnome-session.target to just
gnome.target to make it less likely to be mixed up with
gnome-session.service:

  http://people.canonical.com/~pitti/tmp/session.sh

This makes it much easier to mess around with the units and check that
stuff still works. This is now as simple as I could get it without
breaking the desired behaviour:

 * Starting gnome.target starts gnome-session.service,
   someapp.service, and graphical.target.

 * Stopping gnome.target OR graphical.target stops the services.

 * Stopping or killing gnome-session.target stops everything else.

 * someapp.service starts along with the session but can be
   stopped/restarted independently.

So we still have the requirement of an abstract "graphical.target"
that particular session services can be PartOf=, so that we avoid
having to change every service whenever a new session type arrives.

This works on systemd 230 as-is, without the need to change anything.

Note that this writes units into ~/.config/systemd/user, so if you run
this you need to clean up that dir afterwards.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Jan Alexander Steffens]

On Wed, Jul 6, 2016 at 2:21 PM Jóhann B. Guðmundsson 
wrote:

>
> It's questionable if such application should reside in upstream systemd
> since arguably systemd should have never created the graphical.target to
> begin with ( if it had not we probably would not be having this discussion
> since desktop environment targets would have been created instead ).
>


What do you mean? There is no user-level graphical.target in systemd (yet),
and this discussion has nothing to do with the system-level
graphical.target.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Jan Alexander Steffens]

On Wed, Jul 6, 2016 at 1:50 PM Martin Pitt  wrote:

> Martin Pitt [2016-07-06 13:47 +0200]:
> > I have a gut feeling that this should be expressible with systemd
> > dependencies -- i. e. "if gnome-session.service stops, then stop
> > gnome-session.target". Naïvely this would be
> > "PartOf=gnome-session.target" in gnome-session.service, but this does
> > not currently work (that might be the same bug I mentioned in my other
> > reply).
>
> Sorry, wrong way around according to how PartOf= works: I meant
> "PartOf=gnome-session.service" in gnome-session.target. (But that
> doesn't work either).
>

Note that systemd makes a difference between "gnome-session.service became
inactive" and "gnome-session.service gets stopped". A service terminating
by itself is the former.

Requires= and PartOf= will only propagate the latter. BindsTo= also stops
on the former (besides acting like Requires=).

So, if gnome-session.target BindsTo=gnome-session.service,
gnome-session.target requires gnome-session.service and will be stopped
when the service exits.

There's also StopWhenUnneeded=, which might useful on the targets.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Simon McVittie [2016-07-05 10:27 +0100]:
> On 04/07/16 21:01, Martin Pitt wrote:
> > A session type like "GNOME" or "KDE" then defines which top-level
> > servcies it wants.
> 
> Could this be done by having the .desktop file in /usr/share/xsessions
> or /usr/share/wayland-sessions start an appropriate systemd user unit
> directly, and wait for it to terminate?

There is currently no command (other than a polling loop) to wait
until a particular unit gets stopped. I.  e.

  Exec=gnome-session --session=gnome

would need to be replaced with something like

  Exec=/bin/sh -c "systemctl start gnome-session.target; 
wait-until-service-stopped gnome-session.service; systemctl stop 
gnome-session.target"

and gnome-session.target pulls in gnome-session.service (which then
runs the actual gnome-session program).

Note the difference between the target (which is the whole GNOME
session) and the service (which is just the gnome-session program itself).

> > Ideally we could hook the startup of graphical.slice into the system
> > logind scope; but as the user systemd does not "see" the
> > systemd users, this isn't possible. So for now pretty much the only
> > way is to go via an /X11/xinit/xinitrc.d (Fedora) or
> > /etc/X11/Xsession.d/ (Debian) script
> 
> These scripts are a necessary evil for X11, but in the Wayland future,
> the plan (at least in GNOME) seems to be for them not to be replicated;
> if gdm is told to launch a session from /usr/share/wayland-sessions, it
> doesn't execute X11 startup script snippets. (It does have a
> gdm-specific way to set environment variables, and I'm planning to
> extend pam_env to support systemd-style .d drop-in directories to
> generalize that.) A more declarative session startup seems like a better
> session startup.

Agreed. In my original proposal I said that it might be better to let
the DMs start/stop $SESSION.target/graphical.target directly, but
indeed that's harder to change/see. Creating a nice wrapper/helper for
the above horrible Exec= line and using that in the session .desktop
file sounds better. That wrapper needs the target to start and the
"session leader unit" on whose stopping the target gets stopped as
well.

I have a gut feeling that this should be expressible with systemd
dependencies -- i. e. "if gnome-session.service stops, then stop
gnome-session.target". Naïvely this would be
"PartOf=gnome-session.target" in gnome-session.service, but this does
not currently work (that might be the same bug I mentioned in my other
reply).

> I'm not sure what you do for Mir in Ubuntu, but I'd advocate a similar
> approach - sourcing a couple of dozen Turing-complete shell script
> fragments during session startup makes it rather difficult to reason about.

Yes, this makes sense. Mir doesn't have the Xsession.d shell scriptery
either, just the .desktop file interface.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Martin Pitt [2016-07-06 13:47 +0200]:
> I have a gut feeling that this should be expressible with systemd
> dependencies -- i. e. "if gnome-session.service stops, then stop
> gnome-session.target". Naïvely this would be
> "PartOf=gnome-session.target" in gnome-session.service, but this does
> not currently work (that might be the same bug I mentioned in my other
> reply).

Sorry, wrong way around according to how PartOf= works: I meant
"PartOf=gnome-session.service" in gnome-session.target. (But that
doesn't work either).

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units -- version 2

[Andrei Borzenkov]

On Wed, Jul 6, 2016 at 2:25 PM, Martin Pitt  wrote:
>$ cat .config/systemd/user/gnome-session.target
>[Unit]
>Description=User systemd services for GNOME graphical session
>Requires=graphical.target
>PartOf=graphical.target
>

Is not this redundant? Requires=graphical.target already stops
gnome-session.target when graphical.target is stopped (by any mean).

...
> The only glitch is that "systemctl --user stop gnome-session.target"
> only stops that target itself. I would have expected it to stop
> graphical.target too (and someapp along with it), as it has
> PartOf=graphical.target. This might be a bug in systemd, or some
> semantics of PartOf with targets that I don't understand.

You probably do not understand. If foo.service is PartOf=bar.target,
then stopping bar.target stops foo.service. State of foo.service
itself has no impact of bar.target.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units -- version 2

[Martin Pitt]

Hello all,

Colin, Jan, Zbigniew, thanks for your input! Based on that I have an
updated proposal.

Jan Alexander Steffens [2016-07-06  9:44 +]:
> On Wed, Jul 6, 2016 at 10:51 AM Colin Guthrie  wrote:
> > Not commenting on the general approach (which I did read and broadly
> > agree with without giving it too much thought!), but could you use
> > PartOf= here to make the target approach work? It might be more hacky as
> > each user .service would have to declare themselves to be PartOf the
> > corresponding .target. This does mean that if the target is stopped, the
> > units are stopped too.
> >
> > I'm not sure how this would work regarding things like g-s-d which you
> > want in multiple DEs.. perhaps the gnome.target would have to be split
> > up into gnome-base.target and gnome.target to allow for this use case?
> > Or perhaps g-s-d could just become bus activated and not need any direct
> > starting?
> >
> 
> How about a top-level, generic graphical.target that defines no
> dependencies itself, but is Required by anything graphical. Then stopping
> graphical.target would terminate the desktop, no matter which environment
> was set up.

This indeed mostly works. So this would have three parts:

 * systemd ships a new user unit "graphical.target", symmetric to the
   system unit:

   $ cat .config/systemd/user/graphical.target
   [Unit]
   Description=User systemd services for graphical session

   This isn't enabled anywhere, so it's completely inert on servers,
   ssh/VT sessions, etc.


 * gnome-session and friends, which currently ship e. g.
   /usr/share/xsessions/gnome.desktop, ship a corresponding
   gnome-session.target:

   $ cat .config/systemd/user/gnome-session.target
   [Unit]
   Description=User systemd services for GNOME graphical session
   Requires=graphical.target
   PartOf=graphical.target

 * Applications ship services which are PartOf=graphical.target,  so
   that they go down with the graphical session:

   cat .config/systemd/user/someapp.service
   [Unit]
   Description=example graphical app
   PartOf=graphical.target
   [Service]
   ExecStart=/bin/sleep infinity

   graphical.target is the thing we set/ship in systemd, so it's not
   dependent on which particular DE/session you use.

 * The GNOME session package (which ships gnome.desktop and
   gnome-session.target) depends on the things it needs (like
   gnome-session, mutter, etc.) and also ships the top-level
   enablement symlinks:

   .config/systemd/user/gnome-session.target.wants/someapp.service -> 
../someapp.service

   This also retains the option that an app auto-starts itself in all
   graphical sessions by shipping a graphical.target.wants/ symlink to
   themselves (but this shouldn't be a common case).

Now "systemctl --user start gnome-session.target" starts
graphical.target (through g-s.t's Requires) and myapp.service (via
gnome-session.target.wants/). And "systemctl --user stop graphical.target"
stops all three (via the PartOf=).

The only glitch is that "systemctl --user stop gnome-session.target"
only stops that target itself. I would have expected it to stop
graphical.target too (and someapp along with it), as it has
PartOf=graphical.target. This might be a bug in systemd, or some
semantics of PartOf with targets that I don't understand. However,
always stopping graphical.target when the session stops seems safer
anyway.

(The XSession.d/xinit.d bits to actually start/stop the targets are
unaffected by this change; I'll follow up to Simon's reply about that).

So again, the only change we should do in systemd is to ship the
graphical.target user unit.

WDYT?

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Colin Guthrie]

Jan Alexander Steffens wrote on 06/07/16 10:44:
> On Wed, Jul 6, 2016 at 10:51 AM Colin Guthrie  > wrote:
> 
> Martin Pitt wrote on 04/07/16 23:08:
> >> > Why would you call it graphical-<$DE>.slice as opposed to
> simply <$DE>.slice
> >> > which is part of the <$DE>.target and graphical target is link
> to that
> >> > <$DE>.target  ( if shipped upstream it needs to be generic
> enough to cater
> >> > whatever is out there right )
> > target units don't work well as they don't stop their dependencies on
> > stop, as I explained -- unless there's a trick which I'm missing?
> 
> Not commenting on the general approach (which I did read and broadly
> agree with without giving it too much thought!), but could you use
> PartOf= here to make the target approach work? It might be more hacky as
> each user .service would have to declare themselves to be PartOf the
> corresponding .target. This does mean that if the target is stopped, the
> units are stopped too.
> 
> I'm not sure how this would work regarding things like g-s-d which you
> want in multiple DEs.. perhaps the gnome.target would have to be split
> up into gnome-base.target and gnome.target to allow for this use case?
> Or perhaps g-s-d could just become bus activated and not need any direct
> starting?
> 
> 
> How about a top-level, generic graphical.target that defines no
> dependencies itself, but is Required by anything graphical. Then
> stopping graphical.target would terminate the desktop, no matter which
> environment was set up.
> 
> I was thinking of a direct Requires on all units, but maybe transitive
> Requires via intermediate targets would be useful, too.

I didn't read the whole thread :( The suggestion of adding a
DependenciesPartOf=yes|no directive to target units is a good suggestion
IMO and solves this same problem too (if I understand correctly - the
target can just add a Requires= check for each accordingly, e.g.
xfce.target can Require=g-s-d.service quite happily)

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Jan Alexander Steffens]

On Wed, Jul 6, 2016 at 10:51 AM Colin Guthrie  wrote:

> Martin Pitt wrote on 04/07/16 23:08:
> >> > Why would you call it graphical-<$DE>.slice as opposed to simply
> <$DE>.slice
> >> > which is part of the <$DE>.target and graphical target is link to that
> >> > <$DE>.target  ( if shipped upstream it needs to be generic enough to
> cater
> >> > whatever is out there right )
> > target units don't work well as they don't stop their dependencies on
> > stop, as I explained -- unless there's a trick which I'm missing?
>
> Not commenting on the general approach (which I did read and broadly
> agree with without giving it too much thought!), but could you use
> PartOf= here to make the target approach work? It might be more hacky as
> each user .service would have to declare themselves to be PartOf the
> corresponding .target. This does mean that if the target is stopped, the
> units are stopped too.
>
> I'm not sure how this would work regarding things like g-s-d which you
> want in multiple DEs.. perhaps the gnome.target would have to be split
> up into gnome-base.target and gnome.target to allow for this use case?
> Or perhaps g-s-d could just become bus activated and not need any direct
> starting?
>

How about a top-level, generic graphical.target that defines no
dependencies itself, but is Required by anything graphical. Then stopping
graphical.target would terminate the desktop, no matter which environment
was set up.

I was thinking of a direct Requires on all units, but maybe transitive
Requires via intermediate targets would be useful, too.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Colin Guthrie]

Martin Pitt wrote on 04/07/16 23:08:
>> > Why would you call it graphical-<$DE>.slice as opposed to simply 
>> > <$DE>.slice
>> > which is part of the <$DE>.target and graphical target is link to that
>> > <$DE>.target  ( if shipped upstream it needs to be generic enough to cater
>> > whatever is out there right )
> target units don't work well as they don't stop their dependencies on
> stop, as I explained -- unless there's a trick which I'm missing?

Not commenting on the general approach (which I did read and broadly
agree with without giving it too much thought!), but could you use
PartOf= here to make the target approach work? It might be more hacky as
each user .service would have to declare themselves to be PartOf the
corresponding .target. This does mean that if the target is stopped, the
units are stopped too.

I'm not sure how this would work regarding things like g-s-d which you
want in multiple DEs.. perhaps the gnome.target would have to be split
up into gnome-base.target and gnome.target to allow for this use case?
Or perhaps g-s-d could just become bus activated and not need any direct
starting?

Col

-- 
-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Simon McVittie]

On 04/07/16 21:01, Martin Pitt wrote:
> A session type like "GNOME" or "KDE" then defines which top-level
> servcies it wants.

Could this be done by having the .desktop file in /usr/share/xsessions
or /usr/share/wayland-sessions start an appropriate systemd user unit
directly, and wait for it to terminate?

> Ideally we could hook the startup of graphical.slice into the system
> logind scope; but as the user systemd does not "see" the
> systemd users, this isn't possible. So for now pretty much the only
> way is to go via an /X11/xinit/xinitrc.d (Fedora) or
> /etc/X11/Xsession.d/ (Debian) script

These scripts are a necessary evil for X11, but in the Wayland future,
the plan (at least in GNOME) seems to be for them not to be replicated;
if gdm is told to launch a session from /usr/share/wayland-sessions, it
doesn't execute X11 startup script snippets. (It does have a
gdm-specific way to set environment variables, and I'm planning to
extend pam_env to support systemd-style .d drop-in directories to
generalize that.) A more declarative session startup seems like a better
session startup.

I'm not sure what you do for Mir in Ubuntu, but I'd advocate a similar
approach - sourcing a couple of dozen Turing-complete shell script
fragments during session startup makes it rather difficult to reason about.

S

-- 
Simon McVittie
Collabora Ltd. 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Zbigniew Jędrzejewski-Szmek]

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Martin Pitt]

Hello Jóhann,

Jóhann B. Guðmundsson [2016-07-04 20:53 +]:
> Shipping an predefined desktop units arguably does not belong upstream since
> it's just catering to one ( desktop ) out of three (
> embedded/server/desktop) target user base.

Right, embedded/server would never start this new unit. But we also
ship a graphical.target on the system side, even though that doesn't
apply to servers either. This is just an extra two-line unit.

Also, if that is really an issue, we do not *need* to ship an actual
unit file for that -- we merely need to define what its name is, so
that we can start shipping such units in upstream desktop projects.

> It might result in other two target user base having to patch things
> out in the environment.

What would you need to patch out? Having an extra unused unit on them
isn't going to cause any harm, other than the extra microsecond to
read the unit file (but we already parse plenty).

> Why would you call it graphical-<$DE>.slice as opposed to simply <$DE>.slice
> which is part of the <$DE>.target and graphical target is link to that
> <$DE>.target  ( if shipped upstream it needs to be generic enough to cater
> whatever is out there right )

target units don't work well as they don't stop their dependencies on
stop, as I explained -- unless there's a trick which I'm missing?

If you just make it a top-level slice like "gnome.slice", then you
don't have a parent like "graphical.slice" any more which you can
refer to in units. We certainly don't want to use the root slice
(-.slice) as we don't want to kill *all* the user services on
graphical logout.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Standardizing names for graphical session units

[Jóhann B . Guðmundsson]

On 07/04/2016 08:01 PM, Martin Pitt wrote:


Feedback appreciated!


Shipping an predefined desktop units arguably does not belong upstream 
since it's just catering to one ( desktop ) out of three ( 
embedded/server/desktop) target user base.  It might result in other two 
target user base having to patch things out in the environment.


Why would you call it graphical-<$DE>.slice as opposed to simply 
<$DE>.slice which is part of the <$DE>.target and graphical target is 
link to that <$DE>.target  ( if shipped upstream it needs to be generic 
enough to cater whatever is out there right )


JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel