Hey Andrei, Andrei Borzenkov [2015-01-17 16:00 +0300]: > > | [email protected] > > | [email protected] > > After should be redundant here - Requires implies After for target.
No, both are required in this case. If you just say Requires, then [email protected] 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 [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. 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 [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. Oh, thanks for the hint! This indeed does what I need -- re-evaluate ifup-all-auto.target everytime an [email protected] 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 [email protected] 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)
signature.asc
Description: Digital signature
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
