[systemd-devel] [PATCH] unit: When stopping due to BindsTo=, log which unit caused it

Alban Crequy alban at endocode.com
Wed Apr 22 07:55:50 PDT 2015


On Tue, Apr 21, 2015 at 10:35 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Tue, Apr 21, 2015 at 03:54:35PM +0200, Alban Crequy wrote:
>> On Sat, Feb 28, 2015 at 5:40 PM, Lennart Poettering
>> <lennart at poettering.net> wrote:
>> > On Fri, 27.02.15 17:13, Lennart Poettering (lennart at poettering.net) wrote:
>> >
>> >> On Thu, 26.02.15 16:50, Martin Pitt (martin.pitt at ubuntu.com) wrote:
>> >>
>> >> > IMHO it would be prudent to skip adding the BindsTo= if at the time of
>> >> > creating the .mount unit the backing .device unit doesn't actually
>> >> > exist. In that case it's a mount which isn't managed by systemd, and
>> >> > we shouldn't touch it. We mostly want this BindsTo= for mounts where
>> >> > the .device units *do* exist, so that when they go away we can clean
>> >> > up the mount (mostly for hotpluggable devices and removable media).
>> >> > I'll have a deeper look ASAP.
>> >>
>> >> I ran into this myself the other day, and Kay, Daniel and I spent a
>> >> lot of time to come up with a scheme how to deal with the race... And
>> >> I think we have a nice scheme now and I started implementing it.
>> >>
>> >> The idea is that .device units will gain a third state: currently they
>> >> are either "dead" or "plugged", and the new state will be
>> >> "tentative". It is entered when a device is referenced in
>> >> /proc/self/mountinfo or /proc/swap, even though it has not yet shown
>> >> up via udev.
>> >>
>> >> This new state has will not result in BindsTo= getting active.
>> >
>> > This is implemented now. Please check if this fixes this issue for
>> > you.
>>
>> Which commit implements this?
>>
>> I have an issue on nspawn container shutdown with v219 that I didn't
>> have with v215. Systemd is trying to unmount the volumes bind mounted
>> by nspawn and it fails because /bin/umount does not exist in my
>> container. Systemd keeps trying to umount it in a busy loop. Reverting
>> 06e97888883e2cc12eb6514e80c7f0014295f59b ("core/mount: add
>> dependencies to dynamically mounted mounts too") fixes my issue.
> There was a bunch of fixes on top. See 5bd4b173605142, 628c89cc68ab96fce2d,
> 496068a8288084ab3.

Thanks for the commits. They don't seem related to containers.

I can reproduce my issue on git-master:

sudo ~/git/systemd/systemd-nspawn --register=false --bind
$HOME/tmp/vol -D debian-tree -b

Then, in the container, make sure /bin/umount does NOT exist.
Then halt the container with kill -37 1 (SIGRTMIN+3)

It will loop forever on:

[  OK  ] Failed unmounting /home/alban/tmp/vol.
         Unmounting /home/alban/tmp/vol...
[  OK  ] Failed unmounting /home/alban/tmp/vol.
         Unmounting /home/alban/tmp/vol...

I am not sure why it worked fine for me with the older version v215.

Cheers,
Alban


More information about the systemd-devel mailing list