[systemd-devel] Target updating status for dependencies

Andrei Borzenkov arvidjaar at gmail.com
Sat Jan 17 05:00:18 PST 2015


В Wed, 14 Jan 2015 09:47:20 +0100
Martin Pitt <martin.pitt at ubuntu.com> пишет:

> 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
> | Requires=ifup at eth0.service
> | After=ifup at eth0.service

After should be redundant here - Requires implies After for target.

> | Requires=ifup at eth42.service
> | After=ifup at eth42.service
> |
> | [Install]
> | RequiredBy=network-online.target
> 
> After booting, ifup at eth0.service 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 at eth0 (SUCCESS)     ifup at 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 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. 

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

> Thanks in advance for any insights!
> 
> Martin
> 
> [1] ip link add name eth42 type veth peer name veth42
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150117/0ea5323d/attachment.sig>


More information about the systemd-devel mailing list