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

[Didier Roche]

Le 04/03/2015 13:40, Lennart Poettering a écrit :
> On Wed, 04.03.15 13:19, Didier Roche (didrocks at ubuntu.com) wrote:
>
>> 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.

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:

$ 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: man:systemd-timesyncd.service(8)

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: man:hier(7)
            http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150306/5f12a2d1/attachment.html>