From: Phillip Susi <psusi@ubuntu.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: Thomas Orgis <thomas-forum@orgis.org>, util-linux@vger.kernel.org
Subject: Re: losetup -d --force for zombie loop devices?
Date: Fri, 11 Jan 2013 19:54:16 -0500 [thread overview]
Message-ID: <50F0B438.1080608@ubuntu.com> (raw)
In-Reply-To: <201301111852.03607.vapier@gentoo.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/11/2013 06:52 PM, Mike Frysinger wrote:
> On Thursday 03 May 2012 10:29:07 Phillip Susi wrote:
>> If you want to hide mounts from certain processes, that is what
>> unshare is for. Hiding a mount from all processes does not make
>> sense. If you know a mount is gone and beyond recovery ( like in
>> this loop over nfs case, or removed media ), then it should be
>> forcibly unmounted, not simply made invisible and doomed to
>> remain a zombie mount until the system is rebooted.
>
> in an ideal world, maybe unshare might work. in the real world, it
> doesn't. you can use it only on *new* processes, not ones that are
> already running. nor can you do `unshare shutdown` and have it work
> since that simply signals a long running init process to initiate a
> shutdown.
>
> an nfs server goes afk and attempts to `umount` it timeout, as well
> as many desktop programs (like kde io daemons that like to walk
> available mount points) or shutdown processes. no call to
> `unshare` will fix this, but certainly forcibly removing it with
> `umount -l` will. -mike
A bit of a delayed response there, but my point was that what you are
looking for is umount -f, not umount -l. It also used to be that once
you detached a mount with umount -l, you could not reattach it.
Attempts to remount would fail with EBUSY and so this was a horribly
broken state to be in. At some point it seems this was changed and
now you *can* reattach, so lazy unmount is no longer pure evil, but
still it is no forced unmount.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQEcBAEBAgAGBQJQ8LQ4AAoJEJrBOlT6nu75BO0H/A1mZ3qYAfSe/H8Z4x3BVsOZ
/sKYxc6JWUVrK5xfycZlZzpkRsIHL0Jj+asYe/+OAUHHmaUKooR7HuGF90U4kitN
h+UEdyNJJkgldju2rwePyIGucit/HOxz/SfWtSALUiu7w9OIpmkqcCXIINLJvQ0R
nQHLm79d5YFWXQRgKRuloDIW6+kBSq0cpZ+63CFhz2G7CuqzZaa1rE+I1TZbcOzF
p7G8dM/3//BeMZw/yFFDu1Ia2snO3o3vdrZWIZlbVu7fnDXC+a/qfcZtGRNZVZP9
iD4fpPNsKrjLGuaCormk62lm1OBT5YyolKaZPSJWDJrpkwKotndcwVrXWYsKGqY=
=i+ji
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2013-01-12 0:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-17 8:03 losetup -d --force for zombie loop devices? Thomas Orgis
2012-04-17 14:58 ` Mike Frysinger
2012-04-17 21:02 ` Thomas Orgis
2012-04-30 20:03 ` Phillip Susi
2012-04-30 20:07 ` Mike Frysinger
2012-05-01 15:23 ` Phillip Susi
2012-05-03 4:43 ` Mike Frysinger
2012-05-03 14:29 ` Phillip Susi
2013-01-11 23:52 ` Mike Frysinger
2013-01-12 0:54 ` Phillip Susi [this message]
2013-01-12 4:52 ` Mike Frysinger
2013-01-12 5:13 ` Phillip Susi
2013-01-12 5:29 ` Mike Frysinger
2013-01-14 8:35 ` Karel Zak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50F0B438.1080608@ubuntu.com \
--to=psusi@ubuntu.com \
--cc=thomas-forum@orgis.org \
--cc=util-linux@vger.kernel.org \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox