Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #70213 > unrolled thread

broken mount behaviour on jessie

Back to article view | Back to linux.debian.devel

Contents

  broken mount behaviour on jessie Peter Palfrader <weasel@debian.org> - 2016-01-31 11:50 +0100
    Re: broken mount behaviour on jessie Tollef Fog Heen <tfheen@err.no> - 2016-01-31 20:40 +0100
    Re: broken mount behaviour on jessie Brian May <bam@debian.org> - 2016-01-31 22:40 +0100
      Re: broken mount behaviour on jessie Michael Biebl <biebl@debian.org> - 2016-01-31 23:10 +0100
        Re: broken mount behaviour on jessie Brian May <bam@debian.org> - 2016-02-01 12:30 +0100
          Re: broken mount behaviour on jessie Peter Palfrader <weasel@debian.org> - 2016-02-01 12:50 +0100
          Re: broken mount behaviour on jessie Raphael Hertzog <hertzog@debian.org> - 2016-02-01 14:10 +0100
            Re: broken mount behaviour on jessie Brian May <bam@debian.org> - 2016-02-07 01:50 +0100
              Re: broken mount behaviour on jessie Brian May <bam@debian.org> - 2016-02-11 03:40 +0100
                Re: broken mount behaviour on jessie Sebastian Kuzminsky <seb@highlab.com> - 2016-02-11 05:50 +0100

#70213 — broken mount behaviour on jessie

Trying to figure out why my schroot builds keep failing after
upgrading to jessie, I finally narrowed it down to broken behaviour with
mount on jessie:

} root@valiant:/mnt# find
} .
} ./tmp1
} ./tmp1/dev
} ./tmp0
} ./tmp0/dev

Two trees, with a dev directory each.

Let's mount /dev and /dev/pts there:

} root@valiant:/mnt# /bin/mount -v -t none -o rw,bind /dev tmp0/dev
} mount: /dev bound on /mnt/tmp0/dev.
} root@valiant:/mnt# /bin/mount -v -t none -o rw,bind /dev/pts tmp0/dev/pts
} mount: /dev/pts bound on /mnt/tmp0/dev/pts.
} root@valiant:/mnt# grep /mnt /proc/mounts
} udev /mnt/tmp0/dev devtmpfs rw,relatime,size=10240k,nr_inodes=3087992,mode=755 0 0
} devpts /mnt/tmp0/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Seems to have worked.  Yay.

Now the second tree:

} root@valiant:/mnt# /bin/mount -v -t none -o rw,bind /dev tmp1/dev
} mount: /dev bound on /mnt/tmp1/dev.
} root@valiant:/mnt# grep /mnt /proc/mounts
} udev /mnt/tmp0/dev devtmpfs rw,relatime,size=10240k,nr_inodes=3087992,mode=755 0 0
} devpts /mnt/tmp0/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
} udev /mnt/tmp1/dev devtmpfs rw,relatime,size=10240k,nr_inodes=3087992,mode=755 0 0

So far, so good.  Now for /dev/pts:

} root@valiant:/mnt# /bin/mount -v -t none -o rw,bind /dev/pts tmp1/dev/pts
} mount: /dev/pts bound on /mnt/tmp1/dev/pts.
} root@valiant:/mnt# grep /mnt /proc/mounts
} udev /mnt/tmp0/dev devtmpfs rw,relatime,size=10240k,nr_inodes=3087992,mode=755 0 0
} devpts /mnt/tmp0/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
} udev /mnt/tmp1/dev devtmpfs rw,relatime,size=10240k,nr_inodes=3087992,mode=755 0 0
} devpts /mnt/tmp1/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
} devpts /mnt/tmp0/dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Something's fishy here.  Note how there is now a second mount on
tmp0/dev/pts.


This is a real problem as exhibited in these two use-cases:

o) you cannot unmount the tmp0 tree while the tmp1 tree is busy:

} root@valiant:/mnt# (cd tmp1/dev/pts ; sleep 10 &)
} root@valiant:/mnt# umount /mnt/tmp0/dev/pts
} umount: /mnt/tmp0/dev/pts: target is busy
}         (In some cases useful info about processes that
}          use the device is found by lsof(8) or fuser(1).)

o) if it's not busy, and you try to umount the tmp0 tree, you mess with
   the tmp1 tree instead:

} root@valiant:/mnt# ls /mnt/tmp0/dev/pts
} 0  1  10  11  13  14  15  16  17  18  19  2  20  21  22  23  24  25  26  3  4  5  6  7  8  ptmx
} root@valiant:/mnt# ls /mnt/tmp1/dev/pts
} 0  1  10  11  13  14  15  16  17  18  19  2  20  21  22  23  24  25  26  3  4  5  6  7  8  ptmx
} root@valiant:/mnt# umount /mnt/tmp0/dev/pts
} root@valiant:/mnt# ls /mnt/tmp0/dev/pts
} 0  1  10  11  13  14  15  16  17  18  19  2  20  21  22  23  24  25  26  3  4  5  6  7  8  ptmx
} root@valiant:/mnt# ls /mnt/tmp1/dev/pts
} root@valiant:/mnt#

It has been suggested on IRC that this is due to systemd mounting
filesystems with O_SHARE.  Regardless of why, these two things at the
bottom are horribly broken.  We need to fix this somehow.

Cheers,
-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

[toc] | [next] | [standalone]

#70223

]] Peter Palfrader 

> It has been suggested on IRC that this is due to systemd mounting
> filesystems with O_SHARE.  Regardless of why, these two things at the
> bottom are horribly broken.  We need to fix this somehow.

This looks a lot like
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739593 .

https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt
is also useful reading.

It sounds like one should really use --make-slave when mounting.  Doing
that on my stretch system ends up with me having the right directories
mounted.

I think the best here would be to get this fixed in schroot to make it
pass --make-slave when mounting.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

[toc] | [prev] | [next] | [standalone]

#70224

Peter Palfrader <weasel@debian.org> writes:

> o) you cannot unmount the tmp0 tree while the tmp1 tree is busy:
>
> } root@valiant:/mnt# (cd tmp1/dev/pts ; sleep 10 &)
> } root@valiant:/mnt# umount /mnt/tmp0/dev/pts
> } umount: /mnt/tmp0/dev/pts: target is busy
> }         (In some cases useful info about processes that
> }          use the device is found by lsof(8) or fuser(1).)

Sounds very much like the reason behind #794828, which has been a
constant problem for me.

Are there any workarounds for Jessie?
-- 
Brian May <bam@debian.org>

[toc] | [prev] | [next] | [standalone]

#70225

[Multipart message — attachments visible in raw view] — view raw

Am 31.01.2016 um 22:31 schrieb Brian May:
> Peter Palfrader <weasel@debian.org> writes:
> 
>> o) you cannot unmount the tmp0 tree while the tmp1 tree is busy:
>>
>> } root@valiant:/mnt# (cd tmp1/dev/pts ; sleep 10 &)
>> } root@valiant:/mnt# umount /mnt/tmp0/dev/pts
>> } umount: /mnt/tmp0/dev/pts: target is busy
>> }         (In some cases useful info about processes that
>> }          use the device is found by lsof(8) or fuser(1).)
> 
> Sounds very much like the reason behind #794828, which has been a
> constant problem for me.
> 
> Are there any workarounds for Jessie?

Have you tried the patch in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786566


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[toc] | [prev] | [next] | [standalone]

#70233

Michael Biebl <biebl@debian.org> writes:

> Have you tried the patch in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786566

I see two patches here - one patch applies easy enough to schroot -
1.6-schroot-mount-make-bind-mounts-private.patch

I am not sure what the
master-libexec-mount-make-bind-mounts-private.patch is for, it seems to
patch files not in schroot but has references to schroot files.

Do I need the 2nd patch or is the 1st one sufficient?
-- 
Brian May <bam@debian.org>

[toc] | [prev] | [next] | [standalone]

#70234

On Mon, 01 Feb 2016, Brian May wrote:

> Michael Biebl <biebl@debian.org> writes:
> 
> > Have you tried the patch in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786566
> 
> I see two patches here - one patch applies easy enough to schroot -
> 1.6-schroot-mount-make-bind-mounts-private.patch
> 
> I am not sure what the
> master-libexec-mount-make-bind-mounts-private.patch is for, it seems to
> patch files not in schroot but has references to schroot files.
> 
> Do I need the 2nd patch or is the 1st one sufficient?

The first seems to have helped significantly for schroot.

It doesn't, of course, fix the inherent brokeness that can be observed
by the sysadmin doing other mount things.

Also, it is still racy, as it first mounts the target and afterwards
modifies flags.

Cheers,
-- 
                            |  .''`.       ** Debian **
      Peter Palfrader       | : :' :      The  universal
 https://www.palfrader.org/ | `. `'      Operating System
                            |   `-    https://www.debian.org/

[toc] | [prev] | [next] | [standalone]

#70236

Hi,

On Mon, 01 Feb 2016, Brian May wrote:
> I see two patches here - one patch applies easy enough to schroot -
> 1.6-schroot-mount-make-bind-mounts-private.patch
> 
> I am not sure what the
> master-libexec-mount-make-bind-mounts-private.patch is for, it seems to
> patch files not in schroot but has references to schroot files.
> 
> Do I need the 2nd patch or is the 1st one sufficient?

Both patches are the same but for two different schroot branches (1.7.x is
in experimental, 1.6.x in unstable).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#70333

Raphael Hertzog <hertzog@debian.org> writes:

> Both patches are the same but for two different schroot branches (1.7.x is
> in experimental, 1.6.x in unstable).

I have a patched 1.6.10-2 for sid and jessie, amd64 and i386 at
https://linuxpenguins.xyz/debian/pool/main/s/schroot/

Haven't had a chance to test it extensively yet, but so far seems to
work.
-- 
Brian May <bam@debian.org>

[toc] | [prev] | [next] | [standalone]

#70440

Brian May <bam@debian.org> writes:
> I have a patched 1.6.10-2 for sid and jessie, amd64 and i386 at
> https://linuxpenguins.xyz/debian/pool/main/s/schroot/
>
> Haven't had a chance to test it extensively yet, but so far seems to
> work.

Still getting unexpected mount errors; don't have time to investigate
right now.

schroot.chroot.SchrootCommandError: u'E: 10mount: umount: /var/lib/schroot/mount/jessie-i386-02a65cf6-3770-44b6-a1b8-c2f38d0c090e/dev: target is busy\nE: 10mount:         (In some cases useful info about processes that\nE: 10mount:          use the device is found by lsof(8) or fuser(1).)\nE: jessie-i386-02a65cf6-3770-44b6-a1b8-c2f38d0c090e: Chroot setup failed: stage=setup-stop\n'
-- 
Brian May <bam@debian.org>

[toc] | [prev] | [next] | [standalone]

#70447

On Feb 10, 2016 19:34, Brian May <bam@debian.org> wrote:
>
> Brian May <bam@debian.org> writes: 
> > I have a patched 1.6.10-2 for sid and jessie, amd64 and i386 at 
> > https://linuxpenguins.xyz/debian/pool/main/s/schroot/ 
> > 
> > Haven't had a chance to test it extensively yet, but so far seems to 
> > work. 
>
> Still getting unexpected mount errors; don't have time to investigate 
> right now. 
>
> schroot.chroot.SchrootCommandError: u'E: 10mount: umount: /var/lib/schroot/mount/jessie-i386-02a65cf6-3770-44b6-a1b8-c2f38d0c090e/dev: target is busy\nE: 10mount:         (In some cases useful info about processes that\nE: 10mount:          use the device is found by lsof(8) or fuser(1).)\nE: jessie-i386-02a65cf6-3770-44b6-a1b8-c2f38d0c090e: Chroot setup failed: stage=setup-stop\n' 
> -- 
> Brian May <bam@debian.org> 
>

This might be related to an issue I'm seeing: https://lists.debian.org/debian-devel/2016

Try stopping all systems services that use PrivateTmp=yes.

-- 
Sebastian Kuzminsky

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web