Le 06/03/2015 16:17, Michael Biebl a écrit :
2015-03-06 11:20 GMT+01:00 Didier Roche <[email protected]>:
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
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
