[systemd-devel] Requires and After

Michael Chapman mike at very.puzzling.org
Wed Jan 2 09:08:56 UTC 2019


On Wed, 2 Jan 2019, Jérémy Rosen wrote:
> 
> > In my opinion, I don't think the extra inconsistency we get from this is
> > worth it. It literally only saves one line in a unit file.
> >
> It's not about saving a line in the unit file, it's about avoiding errors on
> the most common case
> 
> i.e if A Requires B, you would expect failures of B to prevent A from
> starting.
> * This is not the case if B is (randomly) scheduled after A.
> * This is the case if B is (randomly) scheduled before A.
> This is the race the implicit After= would prevent.
> 
> That being said... the fact that Requires influences both startup and 
> restart/shutdown makes things a bit more complicated...
>
> From reading the documentation it seems that Requires without After is 
> equivalent to PartOf and thus is suspicious (if you want PartOf, you 
> should use PartOf, if you want Requires, the you should also use After)

Well, PartOf= doesn't provide any forward activation dependencies, so it's 
not exactly equivalent.

> This means that there are cases to be checked for but I still globally 
> think that Requires without After is suspicious, and that an implicit 
> order would make sense... but that's just my opinion and I am still a 
> bit confused about the fine-details of what Requires does.
> 
> my understanding is
> 
> Requires = Wants + Requisite + PartOf
> 
> is that correct ?

I think it's just:

  Requires = Wants + PartOf

Wants= propagates "start" and "restart" jobs as "start" jobs on the other 
unit.

ConsistsOf= (the inverse of PartOf=) propagates "stop" and "restart" jobs 
as "stop" and "try-restart" jobs respectively on the other unit.

So Wants= configures activation dependencies in one direction, and 
PartOf= configures deactivation dependencies in the other direction.

(I'm taking this from transaction_add_job_and_dependencies in 
src/core/transaction.c, if anybody wants to check my working.)


More information about the systemd-devel mailing list