On Wed, 04.03.15 13:19, Didier Roche (didro...@ubuntu.com) wrote: > 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.
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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
