[systemd-devel] Target updating status for dependencies

[Martin Pitt]

Hey Andrei,

Andrei Borzenkov [2015-01-17 16:00 +0300]:
> > | Requires=ifup at eth0.service
> > | After=ifup at eth0.service
> 
> After should be redundant here - Requires implies After for target.

No, both are required in this case. If you just say Requires, then
ifup at eth0.service will be started, but that unit won't wait for it to
succeed.

> > So far so good. But now I make eth42 appear (simulating server
> > situations where network interfaces just take a while to init) [1].
> > This causes ifup at eth42.service to get re-triggered via systemd's udev
> > rules, thus the status changes to "active (exited)", i. e. "success".
> > 
> > However, this doesn't seem to cause re-evaluation of the depending
> > units: After that, ifup-all-auto.target (and network-online.target)
> > are still in the same "dependency failed" state.
> > 
> > Calling "systemctl start ifup-all-auto.target" manually updates the
> > status, but at least in this case this should obviously happen
> > automatically.
> > 
> > Is this not how dependencies are supposed to work?
> 
> No. Dependencies really make sense and are evaluated only for the
> running transaction and only between units that are part of running
> transaction. "A Requires B" means - *if* A is being started, B mist
> also be started. It never implied reverse dependency of any sort from B
> to A. 

Yes of course, but that's what I'm doing here -- I have a service that
has Requires/After=network-online.target (see systemd.special(7)).
That service is pulled into boot with WantedBy=multi-user.target. I
had expected that to start network-online.target and start once
network-online.target started, not fail because network-online.target
is waiting for one of its dependencies.

So this "within one transaction" was the part that I didn't
understand.

> >                                                   If not, I suppose I
> > rather need some active program in ifup-all-auto.target which waits
> > for all expected interfaces to appear by itself? 
> 
> I guess it depends on end goal. You can disable timeout for your target
> and it will wait indefinitely

How would I do that? I experimented with JobTimeoutSec=, but it
doesn't seem to make any difference wrt. waiting for dependencies to
become active.

> but then some other unit will likely timeout on startup anyway. You
> do not really want to wait indefinitely during boot. And once boot
> is over, what use this unit has?

Of course these days the line where booting ends and usage starts is
quite blurry, and so is the definition of network-online.target. I was
told that on servers, initializing all network cards may take a while,
so in our Ubuntu upstart world we modeled it so that we have a state
"all network cards are up" which can take up to two minutes after
boot. I need to provide an equivalent for that, and I thought the most
appropriate place would be to delay network-online.target until all
configured ifupdown interfaces appear.

> >                                                  Or can I somehow
> > cause the reverse dependencies of ifup at .service to re-trigger? I
> > didn't see anything obvious in the manpages.
> > 
> 
> You can simply add Wants=ifup-all-auto.target to ifup at .service but I
> still do not see why - this does not make much sense outside booting
> context.

Oh, thanks for the hint! This indeed does what I need -- re-evaluate
ifup-all-auto.target everytime an ifup at .service unit is triggered via
udev. So this part is solved now, the part that's still outstanding is
the above timeout for top-level services which depend on
network-online.target. Obviously I don't want to enumerate all of
those in the network-online.target unit. This is pretty much the same
problem one level up..

(BTW: I'll try to eliminiate the intermediate ifup-all-auto.target and
try to hook the ifup at .service instances directly into
network-online.target in the generator; this was mostly just for
experimentation.)

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150119/8ed0fdbf/attachment-0001.sig>