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

[Lennart Poettering]

On Wed, 04.03.15 13:19, Didier Roche (didrocks at ubuntu.com) wrote:

> Le 04/03/2015 12:49, Lennart Poettering a écrit :
> >On Wed, 04.03.15 09:21, Didier Roche (didrocks at ubuntu.com) wrote:
> >
> >>Hey,
> >>
> >>It seems that we discovered an issue if a service declares some relationship
> >>with a .mount unit.
> >>For instance, having tmp.mount disable (and nothing mounting /tmp as tmpfs
> >>in fstab):
> >tmp.mount is enabled statically via the
> >/usr/lib/systemd/system/local-fs.target.wants/tmp.mount symlink.
>
> We have a distro-patched in debian to remove this symlink. Note that
> otherwise, it wouldn't be started only on some boots and not on others,
> which shows that there is an erratic behavior.

Well, it's affected by jobs later queued in. You are using "Conflicts"
against the unit, apparently. Now, conflicts has different effects for
later queued jobs. depending on the "mode" setting the conflicting job
is either removed, or the unit stopped or the job fails.

> >Use "systemctl show tmp.mount" to see by which dependencies it was
> >pulled in.
> 
> Nice hint! So, on boots where tmp.mount is enabled, here is what systemctl
> show on the unit gives:
> RequiredBy=systemd-timesyncd.service
> Conflicts=umount.target
> ConflictedBy=foo.service

What is this ConflictedBy actually about? Why?

Ihave the suspicion you assume conflicts= has different behaviour that
it actually means.

> Before=systemd-timesyncd.service foo.service local-fs.target umount.target
> 
> systemd-timesyncd.service though is condition failed:
> Condition: start condition failed at Wed 2015-03-04 13:09:09 CET; 3min 10s
> ago
>            ConditionVirtualization=no was not met
> 
> So, even if the condition for an unit failed, the Requires= are
> started? 

Yes. ConditionXYZ= only shortcuts the executon of the service, all its
deps are pulled in. The condition is checked at the time the unit is
about to be started, which means that at that time the dependencies
usually are fulfilled anyway already. 

Also see docs about this in the man page.

> I
> noted that on boot where the tmpfs isn't mounted, systemd-timesyncd.service
> stays inactive:
>    Active: inactive (dead)
> ExecMainStartTimestampMonotonic=0
> ExecMainExitTimestampMonotonic=0
> 
> and if I try to start it (and we get the condition fail), the Requires
> (tmp.mount in that case) is started.
> 
> It seems there are 2 issues:
> - systemd-timesyncd.service is seldomly activated on boot on those machines.
> (I'll dive into why)
> - if an unit as a Condition failing, the Requirements of those units are
> still activated.

Yes, absolutely, see man pages.

Lennart

-- 
Lennart Poettering, Red Hat