[systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?

[Didier Roche]

Le 06/03/2015 16:17, Michael Biebl a écrit :
> 2015-03-06 11:20 GMT+01:00 Didier Roche <didrocks at ubuntu.com>:
>> It seems like tmp.mount unit was skipped as nothing declared any explicit
>> dependency against it. What seems to confirm this is that if I add any
>> enabled foo.service which declares After=tmp.mount, or if I add the After=
>> statement to systemd-timesync.service, then I get tmp.mount reliably to
>> start (and it was installed as the journal shows up). Does it make sense?
> I do have several units which have PrivateTmp=true (cups.service,
> timesyncd) which *are* started during boot, yet tmp.mount is not being
> activated. Inspecting the units via systemctl shows e.g.
>
> $ systemctl show cups.service -p After -p Requires
> Requires=basic.target cups.socket -.mount tmp.mount
> After=cups.socket -.mount system.slice tmp.mount basic.target
> cups.path systemd-journald.socket
>
> Why is tmp.mount then not reliably activated during boot here?
>
Right, that's the question, my feeling is that PrivateTmp=true isn't 
mapped right away as corresponding to tmp.mount at boot time, and so, as 
nothing refers to tmp.mount explicitly, systemd doesn't take that unit 
into account. Then, it's present later (after boot time) and that's why 
starting or restarting an unit with PrivateTmp=true would then pull it.

That would also explains why if you enable a service like foo.service 
declaring a relationship to tmp.mount (like After=tmp.mount), this one 
is reliably seen at boot time from systemd, and thus, reliably started, 
even when booting by any units declaring PrivateTmp=true.
Would that be the bug?

Cheers,
Didier