[systemd-devel] Implicit unit dependency on slice might be too weak ?

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 22, 2015 at 11:52:05AM +0200, Francis Moreau wrote:
> On Tue, Sep 22, 2015 at 11:14 AM, David Herrmann <dh.herrmann at gmail.com> wrote:
> > Hi
> >
> > On Tue, Sep 22, 2015 at 10:58 AM, Francis Moreau <francis.moro at gmail.com> wrote:
> [...]
> >>>
> >>
> >> But what if the slice fails to start ?
> >>
> >> Will the unit asking for a specific slice (which fails to start) be
> >> moved into another slice ? It seems that whatever the final
> >> destination used by systemd, the constraints used by the "fallback"
> >> slice won't be correct, no ?
> >
> > Correct.
> >
> > You still get a big fat error on your screen and you should fix your
> > setup. Again, if that's no suitable, you better use "Requires=".
> >
> 
> To put a unit in a slice, one uses by default
> 
>    Slice=myslice.slice
> 
> and the default behaviour is to add Wants=myslice.slice to the unit.
> 
> If the unit will always fail to start if myslice.slice fails then I
> would say the default  behaviour should be Requires=myslice.slice.
Does it actually fail? If yes, then Requires= would be better. If not,
then Wants= should stay.

(I tried to test this:
- with a slice with ConditionPathExists= that is false, the
  slice is not started and the unit is started.
- with a slice that has [Slice] Slice=<itself>, the unit is neither started
  nor errors out:

Sep 22 08:09:27 yy systemd[1]: xxx.slice located outside its parent slice. Refusing.
Sep 22 08:09:27 yy systemd[1]: Cannot add dependency job for unit xxx.slice, ignoring: Unit xxx.slice failed to load: Invalid argument. See system logs and 'systemctl status xxx.slice' for details.

systemd becomes unresponsive... This looks like a bug. This was
with systemd-219-23.fc22.x86_64, I'll test with something more modern
later.)

Zbyszek