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] Samba Server dosen't start

[Reindl Harald]

Am 06.07.2016 um 07:12 schrieb Lennart Poettering:

On Sun, 26.06.16 14:28, Reindl Harald (h.rei...@thelounge.net) wrote:


Am 26.06.2016 um 14:16 schrieb Tom H:

On Sun, Jun 26, 2016 at 8:09 AM, Reindl Harald  wrote:

Am 26.06.2016 um 13:27 schrieb Ralf Recktenwald:


Smb.conf


how is that a systemd problem?

how do you imagine help without mention distrubition, software-versions,
content of the systemd-unit, systemctl status servicename and so on?


The problem's this journalctl output: "Support:
http://lists.freedesktop.org/mailman/listinfo/systemd-devel";


well, that's indeed a braindead output when some random service fails


Yeah, these catalog entries should be improved. As first step with
v231 downstream can easily override the support URL at build time via
a configure script so that the support URL for things like this at
least doesn't end up with us anymore...


honestly *any* support URL for every random service is plain wrong at 
this place - for samba it#s the samba mailing list, for named it's the 
bind-mailing-list and so on




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

Re: [systemd-devel] How to set a limit for mounting roofs?

[Andrei Borzenkov]

On Wed, Jul 6, 2016 at 7:26 AM, Lennart Poettering
 wrote:
> On Tue, 05.07.16 14:00, Chris Murphy (li...@colorremedies.com) wrote:
>
>> On Tue, Jul 5, 2016 at 12:45 PM, Chris Murphy  
>> wrote:
>> > OK it must be this.
>> >
>> > :/# cat /usr/lib/udev/rules.d/64-btrfs.rules
>> > # do not edit this file, it will be overwritten on update
>> >
>> > SUBSYSTEM!="block", GOTO="btrfs_end"
>> > ACTION=="remove", GOTO="btrfs_end"
>> > ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
>> >
>> > # let the kernel know about this btrfs filesystem, and check if it is 
>> > complete
>> > IMPORT{builtin}="btrfs ready $devnode"
>> >
>> > # mark the device as not ready to be used by the system
>> > ENV{ID_BTRFS_READY}=="0", ENV{SYSTEMD_READY}="0"
>> >
>> > LABEL="btrfs_end"
>>
>> Yep.
>> https://lists.freedesktop.org/archives/systemd-commits/2012-September/002503.html
>>
>> The problem is that with rootflags=degraded it still indefinitely
>> hangs. And even without the degraded option, I don't think the
>> indefinite hang waiting for missing devices is the best way to find
>> out there's been device failures. I think it's better to fail to
>> mount, and end up at a dracut shell.
>
> I figure it would be OK to merge a patch that makes the udev rules
> above set SYSTEMD_READY immediately if the device popped up in case
> some new kernel command line option is set.
>

That won't work. This will make it impossible to mount any btrfs that
needs more than 1 device to actually be mountable (even degraded).
Because then it will announce btrfs as soon as any device is seen and
filesystem will be incomplete and won't mount. And we do not retry
later.

The situation is the same as we had with Linux MD assembly. What is required, is

a) we need a way to query btrfs whether it is mountable (may be degraded)
b) we need some way to define external policy whether we want to mount
degraded btrfs or not. In general case, not just special case of root
filesystem
c) we need some way to wait for more devices to appear before we
attempt degraded mount
d) finally we need some way to actually perform degraded mount when we
decide to do it

This cannot be implemented using current unit dependencies at all. The
only implementation that could be squeezed into existing framework is
separate program that listens to udev events and waits for all devices
to be present. btrfs mount units must then depend on this program.
Then mount unit will depend on this program and wait for it to
complete; successful completion means filesystem can be mounted.

As far as I understand btrfs must be mounted with special option (-o
degraded), so this can be used as policy decision.

This will also make existing udev rules obsolete (and we finally stop
lying about devices availability).

> Hooking up rootflags=degraded with this is unlikely to work I fear, as
> by the time the udev rules run we have no idea yet what systemd wants
> to make from the device in the end. That means knowing this early the
> fact that system wants to mount it as root disk with some specific
> mount options is not really sensible in the design...
>

This fits well in my suggestion if we use "degraded" in fs flags as
indicator that we are allowed to mount filesystem in degraded mode.
___
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]

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

[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

[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

[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

[Jóhann B . Guðmundsson]

On 07/06/2016 08:50 AM, Colin Guthrie wrote:


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?


It wont and it became pretty clear to me when doing the systemd 
integration in Fedora that each desktop environment would end up needing 
it's own ( boot) target and as such they should be labeled by the 
desktop in question ( gnome.target,lxde.target,kde.target etc ) and 
graphical.target would be deprecated and or point to an generic 
abstraction layer for the DM/DE's which the graphical.target would then 
starts, in which the end users would select which Desktop Environment he 
wanted to use to solve the above problem you are referring to.


the application that would be started by the graphical desktop would be 
something along the line of


Choose your desktop

Gnome ( which starts GDM )
LXDE ( which starts LXDE )
KDE ( which starts XDM )
etc..

Basically just display some custom background image with menu entry 
which allows users to select the desktop environment target to be 
started  System boots  --> default.target --> graphical.target ( 
application started in which user selects for example the Gnome desktop 
menu entry ) --> gnome.target is started  which all type units required 
to start the desktop manager are part of ( including the 
gnome-session.target. )


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


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

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

[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

[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

[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 
mailto:johan...@gmail.com>> 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

[systemd-devel] systemd-journald cannot recover after failed rotation due to disk space ?

[Kemppainen, Heikki (Nokia - FI/Espoo)]

Hi!

Is it normal functionality or bug that systemd-journald cannot recover logging 
to journal automatically in case when:
1) root file system gets almoust full
2) journal rotation fails:
[402131.473154] systemd-journald[93]: Failed to create new system journal: No 
space left on device
3) journald-systemd service is running fine according to systemctl status.
4) no new logs are seen in "journalctl -f"
5) then even when disk space is freed enough, the logging does not resume at 
all. No new logs are seen in "journalctl -f"

Only by restarting the systemd-journald service, new logs are seen in 
"journalctl -f"

Br, Heikki K.


___
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 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]

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]

># 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] does "Before=network.target" really work

[Michael Biebl]

2016-07-06 6:41 GMT+02:00 Lennart Poettering :
> On Fri, 24.06.16 18:53, Xin Long (lucien@gmail.com) wrote:
>> ./firewalld.service:Before=network.target
>
> The line for firewalld appears wrong btw. The firewall should really
> be up before the network is even initiated. Hence it should be
> Before=network-pre.target.

I've filed https://github.com/t-woerner/firewalld/issues/137 for this issue
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Zero downtime restart of Web application (Nginx, Puma, JRuby)

[David Timothy Strauss]

You either need a load balancer (less elegant) or need to make use of the
Linux kernel's SO_REUSEPORT option so the new application can bind to the
same port as the old one (at which point the old application should unbind
the port and shut itself down).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to set a limit for mounting roofs?

[Chris Murphy]

On Wed, Jul 6, 2016 at 3:36 AM, Andrei Borzenkov  wrote:
> On Wed, Jul 6, 2016 at 7:26 AM, Lennart Poettering
>  wrote:

>> I figure it would be OK to merge a patch that makes the udev rules
>> above set SYSTEMD_READY immediately if the device popped up in case
>> some new kernel command line option is set.
>>
>
> That won't work. This will make it impossible to mount any btrfs that
> needs more than 1 device to actually be mountable (even degraded).
> Because then it will announce btrfs as soon as any device is seen and
> filesystem will be incomplete and won't mount. And we do not retry
> later.
>
> The situation is the same as we had with Linux MD assembly. What is required, 
> is
>
> a) we need a way to query btrfs whether it is mountable (may be degraded)

BTRFS_IOC_DEVICES_READY, might lack sufficient granularity. There are
more than two states for redundant multiple device volumes; but only
two states for either one device volumes or multiple device volumes
lacking redundancy (raid0 and single profiles).

Basically this ioctl is not telling the complete truth when a
redundant volume is missing just one device (or two for raid6), it
says devices not ready. The complete truth is devices minimally ready,
i.e. a mount sould succeed if rootflags=degraded.



> b) we need some way to define external policy whether we want to mount
> degraded btrfs or not. In general case, not just special case of root
> filesystem
> c) we need some way to wait for more devices to appear before we
> attempt degraded mount
> d) finally we need some way to actually perform degraded mount when we
> decide to do it

Yep. Even in the md and lvm cases, if they were to indicate minimum
devices available for mount, systemd could have a timer to delay mount
attempt for most use cases while other use case would change to
immediately (or never) try degraded mount.

I think systemd needs more information to do the right thing, and that
right information can only come from code responsible for making that
determination. For Btrfs anyway, it's kernel code. I'm not sure where
this would go for mdadm and lvm arrays.



> As far as I understand btrfs must be mounted with special option (-o
> degraded), so this can be used as policy decision.

That's true also. However it's still possible that at the time systemd
goes to mount that the minimum number of devices for successful
degraded mount aren't yet ready. *shrug*




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

Re: [systemd-devel] How to set a limit for mounting roofs?

[Kai Krakow]

Am Wed, 6 Jul 2016 06:26:03 +0200
schrieb Lennart Poettering :

> On Tue, 05.07.16 14:00, Chris Murphy (li...@colorremedies.com) wrote:
> 
> > On Tue, Jul 5, 2016 at 12:45 PM, Chris Murphy
> >  wrote:  
> > > OK it must be this.
> > >
> > > :/# cat /usr/lib/udev/rules.d/64-btrfs.rules
> > > # do not edit this file, it will be overwritten on update
> > >
> > > SUBSYSTEM!="block", GOTO="btrfs_end"
> > > ACTION=="remove", GOTO="btrfs_end"
> > > ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
> > >
> > > # let the kernel know about this btrfs filesystem, and check if
> > > it is complete IMPORT{builtin}="btrfs ready $devnode"
> > >
> > > # mark the device as not ready to be used by the system
> > > ENV{ID_BTRFS_READY}=="0", ENV{SYSTEMD_READY}="0"
> > >
> > > LABEL="btrfs_end"  
> > 
> > Yep.
> > https://lists.freedesktop.org/archives/systemd-commits/2012-September/002503.html
> > 
> > The problem is that with rootflags=degraded it still indefinitely
> > hangs. And even without the degraded option, I don't think the
> > indefinite hang waiting for missing devices is the best way to find
> > out there's been device failures. I think it's better to fail to
> > mount, and end up at a dracut shell.  
> 
> I figure it would be OK to merge a patch that makes the udev rules
> above set SYSTEMD_READY immediately if the device popped up in case
> some new kernel command line option is set.
> 
> Hooking up rootflags=degraded with this is unlikely to work I fear, as
> by the time the udev rules run we have no idea yet what systemd wants
> to make from the device in the end. That means knowing this early the
> fact that system wants to mount it as root disk with some specific
> mount options is not really sensible in the design...

A possible solution could be to fall back to simply announce
SYSTEMD_READY=1 after a sensible timeout instead of waiting forever for
a situation that is unlikely to happen. That way, the system would boot
slowly in the degraded case but it would continue to boot. If something
goes wrong now, it would probably fall back to rescue shell, right?

-- 
Regards,
Kai

Replies to list-only preferred.

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

Re: [systemd-devel] How to set a limit for mounting roofs?

[Kai Krakow]

Am Wed, 6 Jul 2016 06:21:17 +0200
schrieb Lennart Poettering :

> On Mon, 04.07.16 12:32, Chris Murphy (li...@colorremedies.com) wrote:
> 
> > I have a system where I get an indefinite
> > 
> > "A start job is running for dev-vda2.device (xmin ys / no limit)"
> > 
> > Is there a boot parameter to use to change the no limit to have a
> > limit? rd.timeout does nothing. When I use rd.break=pre-mount and
> > use blkid, /dev/vda2 is there and can be mounted with the same mount
> > options as specified with rootflags= on the command line. So I'm not
> > sure why it's hanging indefinitely. I figure with
> > systemd.log_level=debug and rd.debug and maybe rd.udev.debug I
> > should be able to figure out why this is failing to mount.  
> 
> It should be possible to use x-systemd.device-timeout= among the mount
> options in rootflags= to alter the timeout for the device.
> 
> But what precisely do you expect to happen in this case? You'd simply
> choose between "waits forever" and "fails after some time"... A
> missing root device is hardly something you can just ignore and
> proceed...

I think a degraded btrfs is not actually a missing rootfs. Systemd
tries to decide between black and white here - but btrfs also knows
gray. And I don't mean that systemd should incorporate something to
resolve or announce this issue - that's a UI problem: If the device pool
is degraded, it's the UI that should tell the user. I think, some time
in the future btrfs may automatically fall back to degraded mounts just
like software and hardware raid do. Systemd also doesn't decide not to
boot in that case (raid) and wait forever for a device that's not going
to appear. The problem currently is just that btrfs doesn't go degraded
automatically (for reasons that have been outlined in the btrfs list) -
systemd apparently should have a way to work around this. The degraded
case for btrfs is already covered by the fact that you need to supply
degraded to rootflags on the kernel cmdline - otherwise mounting will
fail anyways, no matter if systemd had a workaround or not. So the UI
part is already covered more or less.

I don't think that incorporating rootflags into "btrfs ready" decision
is going to work. And as I understand, using device-timeout will just
turn out as a missing rootfs after timeout and the degraded fs won't be
marked as ready by it. So btrfs maybe needs a special timeout handling
for "btrfs ready", as I wrote in the other post of this thread.

-- 
Regards,
Kai

Replies to list-only preferred.

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