В Wed, 14 Jan 2015 09:47:20 +0100 Martin Pitt <[email protected]> пишет:
> Hello all, > > I have some trouble to understand how unit dependencies work when > they change status. Suppose I have an ifup-all-auto.target (which will > of course be created by a generator, but for experimentation I tried > with a plain unit): > > | [Unit] > | Description=Wait until all "auto" ifupdown interfaces are up > | Before=network-online.target > | [email protected] > | [email protected] After should be redundant here - Requires implies After for target. > | [email protected] > | [email protected] > | > | [Install] > | RequiredBy=network-online.target > > After booting, [email protected] succeeds (active (exited)) as eth0 > actually exists and works etc. But eth42 does not exist, thus it's in > state "failed (Result: exit-code)". Consequently, > > | $ sudo systemctl status ifup-all-auto.target -l > | ● ifup-all-auto.target - Wait until all "auto" ifupdown interfaces are up > | Loaded: loaded (/etc/systemd/system/ifup-all-auto.target; enabled; > vendor preset: enabled) > | Active: inactive (dead) > | > | Jan 14 09:34:58 autopkgtest systemd[1]: Dependency failed for Wait until > all "auto" ifupdown interfaces are up. > | Jan 14 09:34:58 autopkgtest systemd[1]: Job ifup-all-auto.target/start > failed with result 'dependency'. > > (and obviously network-online.target is also in "dependency failed" > state). So we have > > > ifup@eth0 (SUCCESS) ifup@eth42 (FAIL) > | | > v v > ifup-all-auto.target (DEP FAIL) > | > v > network-online.target (DEP FAIL) > > > 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 [email protected] 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. > 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, 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? > Or can I somehow > cause the reverse dependencies of [email protected] to re-trigger? I > didn't see anything obvious in the manpages. > You can simply add Wants=ifup-all-auto.target to [email protected] but I still do not see why - this does not make much sense outside booting context. > Thanks in advance for any insights! > > Martin > > [1] ip link add name eth42 type veth peer name veth42 >
pgpcU_JTvg7DU.pgp
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
