Le 04/03/2015 12:49, Lennart Poettering a écrit :
On Wed, 04.03.15 09:21, Didier Roche (didro...@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:
RequiredBy=systemd-timesyncd.service
Conflicts=umount.target
ConflictedBy=foo.service
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)
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.

Is the last behavior expected?
Didier
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to