[systemd-bugs] [Bug 85746] New: Required units are not started in certain setups

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Nov 1 14:34:57 PDT 2014


https://bugs.freedesktop.org/show_bug.cgi?id=85746

            Bug ID: 85746
           Summary: Required units are not started in certain setups
           Product: systemd
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: general
          Assignee: systemd-bugs at lists.freedesktop.org
          Reporter: lethalman88 at gmail.com
        QA Contact: systemd-bugs at lists.freedesktop.org

With a certain setup some required units may not be started. It is always
reproducible.

S1.service requires/after D.device and S2.service
S1 is activating, thus starts D and S2
S2 starts, which activates D and deactivates D
S1 "can" now start because D has no job running [1] and the device is not asked
to start. Hence D is not there and the service fails to run.

The steps to reproduce are really simple.

Setup some helper files in e.g. /root/tests:

- Create a disk, truncate -s 1M disk
- mkfs.ext4 disk
- mkdir mnt

Add the following two services.

s1.service:

[Unit]
Requires=s2.service dev-loop0.device
After=s2.service dev-loop0.device
[Service]
ExecStart=/bin/mount /dev/loop0 /root/tests/mnt
Type=oneshot

s2.service:

[Service]
ExecStart=/sbin/losetup /dev/loop0 /root/tests/disk
ExecStart=/sbin/losetup -d /dev/loop0
Type=oneshot
RemainAfterExit=true

systemctl start s1

It fails, because /dev/loop0 has been unmounted. I expect instead s1 to hang
waiting for the device, i.e. add back the start job for the device.

[1] http://lxr.devzen.net/source/xref/systemd/src/core/job.c#429

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20141101/5b315377/attachment.html>


More information about the systemd-bugs mailing list