On Wed, Jan 2, 2019 at 4:22 AM James Feeney <ja...@nurealm.net> wrote: > systemd has two different classes of "dependencies": 1) "activation" > dependencies, and 2) "ordering" dependencies. > > An activation dependency does not, a priori, have to obey any rules about > ordering. There are not, automatically, any promises or guarantees about in > what order service units, for instance, might be queued for execution, based > upon a Requires= dependency. > > "Ordering" is an independent characteristic from "Activation". "Activation" > only promises to enqueue a unit, and then, only if the unit is some kind of > unit that can be "executed", such as a timer or service unit. In contrast, > for instance, systemd is only a "passive observer" of a device unit. > "enqueuing" a device unit for "activation" would make no sense in this > context. A *service* unit that *creates* a device unit could be enqueued for > activation, but not the device unit itself. > > If "A Requires B", and you don't like that "A" *might* get enqueued, or get > executed, before "B", then add an "ordering" dependency. "Ordering > dependencies", then, create guarantees about unit activation *ordering*.
What good is an activation dependency without an ordering dependency? Activation by itself guarantees basically nothing. >> . I think a unit in Requires should imply that unit in After too, otherwise >> the requirement isn't really met. Is there a use case for Requires but not >> After? > Are you sure that you were not wondering about "Requisite=", instead of > "Requires="? Yes, I am, though Requisite looks interesting too. > Because, as far as I know, "Requisite=" is completely broken in systemd. How is it broken? -- Olaf _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
