<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">Le 04/03/2015 13:40, Lennart Poettering a écrit : </div> <blockquote cite="mid:20150304124021.GA11695@gardel-login" type="cite"> <pre wrap="">On Wed, 04.03.15 13:19, Didier Roche (<a class="moz-txt-link-abbreviated" href="mailto:didrocks@ubuntu.com">didrocks@ubuntu.com</a>) wrote: </pre> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> Yes, absolutely, see man pages.</pre> </blockquote> Thanks for your answers. So, from this, we should see systemd-timesyncd.service always trying to be activated (failing due to conditions) and bringing up tmp.mount unit with it. However, in a vm (and it seems in some systems), we are seeing different behaviors. Let's focus on the vm which has a minimal environment and the easiest to reproduce: $ systemctl show -p RequiredBy tmp.mount RequiredBy=systemd-timesyncd.service and systemd-timesyncd.service is enabled. We can end up with systemd-timesyncd.service inactive because of condition failed, but tmp.mount is inactive as well: <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;">$ systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: inactive (dead) Condition: start condition failed at Fri 2015-03-06 10:36:21 CET; 29s ago ConditionVirtualization=no was not met Docs: <a class="moz-txt-link-freetext" href="man:systemd-timesyncd.service(8)">man:systemd-timesyncd.service(8)</a> Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/chronyd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/openntpd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/ntpd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionVirtualization=no failed for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: Starting of systemd-timesyncd.service requested but condition failed. Not starting unit. Mar 06 10:36:21 autopkgtest systemd[1]: Job systemd-timesyncd.service/start finished, result=done Mar 06 10:36:21 autopkgtest systemd[1]: Started Network Time Synchronization. $ systemctl status tmp.mount ● tmp.mount - Temporary Directory Loaded: loaded (/lib/systemd/system/tmp.mount; disabled; vendor preset: enabled) Active: inactive (dead) Where: /tmp What: tmpfs Docs: <a class="moz-txt-link-freetext" href="man:hier(7)">man:hier(7)</a> <a class="moz-txt-link-freetext" href="http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems">http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems</a></pre> journald content with debug mode: Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/chronyd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/openntpd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionFileIsExecutable=!/usr/sbin/ntpd succeeded for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: ConditionVirtualization=no failed for systemd-timesyncd.service. Mar 06 10:36:21 autopkgtest systemd[1]: Starting of systemd-timesyncd.service requested but condition failed. Not starting unit. Mar 06 10:36:21 autopkgtest systemd[1]: Job systemd-timesyncd.service/start finished, result=done With no mention at all about tmp.mount in the journal (even no "Installed new job tmp.mount/start as …"). Shouldn't we get tmp.mount always activated if I follow correctly what you told (and the man page)? It seems like tmp.mount unit was skipped as nothing declared any explicit dependency against it. What seems to confirm this is that if I add any enabled foo.service which declares After=tmp.mount, or if I add the After= statement to systemd-timesync.service, then I get tmp.mount reliably to start (and it was installed as the journal shows up). Does it make sense? Cheers, Didier PS: we are discussing independently about enabling or not tmp.mount in debian/ubuntu (but it's quite late for this cycle and not everyone is comfortable with it), but it seems that this behavior is independent from it and a more general bug? </body> </html>