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

Didier Roche didrocks at ubuntu.com
Wed Mar 4 04:19:46 PST 2015

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.

> Also, note that system automatically creates the necessary deps to a
> mount for a variety of cases when something below that mount is
> referenced.
> Disabling a mount unit is not sufficient to not start it, if it
> is referenced explicitly or implicitly by another unit.
> 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:
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? 
I noted that on boot where the tmpfs isn't mounted, 
systemd-timesyncd.service stays inactive:
    Active: inactive (dead)

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.

Is the last behavior expected?

More information about the systemd-devel mailing list