[systemd-devel] Possible bug when a dummy service declares After= and/or Conflicts= a .mount unit?
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:
>> 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
> 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
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
Is the last behavior expected?
More information about the systemd-devel