[systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?
Lennart Poettering
lennart at poettering.net
Fri Apr 24 07:37:02 PDT 2015
On Fri, 06.03.15 16:17, Michael Biebl (mbiebl at gmail.com) wrote:
> 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?
To track this down it would be good seeing a debug boot log for this
case. Also, it would be good to know what "systemctl status" shows for
tmp.mount right after boot.
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list