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

[Alban Crequy]

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.

Cheers,
Alban