[opensuse] sane people - Why can't I umount MY external drive?
i guess systemd has finally driven me to drink. Heading home for a strong one. After seeing the below I feel like I've already had too many! ==> the below was performed without consumption of alcohol or hallucinogenics. I've been mounting and unmounting external drives manually for as long as I can remember. Certainly longer than Linux has existed. Today I run: # umount /dev/sdb1 umount: /mnt: target is busy (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1).) No big deal, I'll just look to see what I forgot to close, etc. # fuser -m /dev/sdb1 /dev/sdb1: 1150rce 1152rce 1206rce 1207rce 1209rce 1312rce 1353rce 1355rce 1358rce 1363rce 1376rce 1377rce 1379rce 1385rce 1387rce 1391rce 1394rce 1402rce 1409rce 1411rce 1448rce 1461rce 1469rce 1470rce 1475rce 1512rce 1631rce 1635rce 1644rce 1658rce 1661rce 1664rce 1665rce 1680rce 1685rce 1728rce 1781rce 1791rce 1801rce 1807rce 1810rce 1811rce 1815rce 1835rce 1839rce 1897rce 2355rce 2378rce 11758rce 18751rce 18849rce 19093rce 19106rce 19120rce 32545rce You've got to be kidding me, what are all those processes that have MY external disk in use? Let's take a look:
ps -p 1150 1152 1206 1207 1209 1312 1353 1355 1358 1363 1376 1377 1379 1385 1387 1391 1394 1402 1409 1411 1448 1461 1469 1470 1475 1512 1631 1635 1644 1658 1661 1664 1665 1680 1685 1728 1781 1791 1801 1807 1810 1811 1815 1835 1839 1897 2355 2378 11758 13674 18739 32545 PID TTY STAT TIME COMMAND 1150 ? Ss 0:00 /usr/lib/systemd/systemd --user 1152 ? Ss 0:00 /usr/bin/ck-launch-session /usr/bin/ssh-agent /etc/X11/xinit/xinitrc 1206 ? S 0:00 dbus-launch --sh-syntax --exit-with-session --close-stderr 1207 ? Ss 0:29 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session 1209 ? Ssl 1:12 ibus-daemon --xim -d 1312 ? S 0:00 /bin/sh /usr/bin/startkde 1353 ? Ss 0:00 kdeinit4: kdeinit4 Running... 1355 ? S 0:00 kdeinit4: klauncher [kdeinit] --fd=9 1358 ? Sl 0:00 /usr/lib/gvfs/gvfsd 1363 ? Sl 0:00 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes 1376 ? Sl 0:00 /usr/lib64/ibus/ibus-dconf 1377 ? Sl 0:06 /usr/lib64/ibus/ibus-ui-gtk3 1379 ? Sl 0:00 /usr/lib64/ibus/ibus-x11 --kill-daemon 1385 ? Sl 0:40 kdeinit4: kded4 [kdeinit] 1387 ? Sl 0:00 /usr/lib/at-spi2/at-spi-bus-launcher 1391 ? S 0:00 /bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3 1394 ? Sl 0:01 /usr/lib/at-spi2/at-spi2-registryd --use-gnome-session 1402 ? Sl 0:23 /usr/lib64/ibus/ibus-engine-simple 1409 ? S 0:00 kdeinit4: kglobalaccel [kdeinit] 1411 ? S 0:00 /usr/lib/bluetooth/obexd 1448 ? S 0:00 /usr/bin/bluedevil-monolithic 1461 ? Sl 0:00 /usr/bin/kactivitymanagerd 1469 ? S 0:00 kwrapper4 ksmserver 1470 ? Sl 0:02 kdeinit4: ksmserver [kdeinit] 1475 ? SLl 0:00 kdeinit4: kwalletd [kdeinit] 1512 ? Sl 5:30 kwin -session 10183181134152000135817484800000075330000_1413657167_189854 1631 ? Sl 70:35 kdeinit4: plasma-desktop [kdeinit] 1635 ? SN 0:00 /usr/bin/baloo_file 1644 ? S 0:00 /usr/bin/kuiserver 1658 ? Sl 0:05 kdeinit4: krunner [kdeinit] 1661 ? Sl 0:00 kdeinit4: kmix [kdeinit] -session 1018318113415200013581748590 1664 ? Sl 5:48 kdeinit4: konsole [kdeinit] -session 1018318113415200014128024 1665 ? Sl 114:36 /usr/lib64/firefox/firefox --sm-config-prefix /firefox-jF4hty/ --sm-client-id 10183181134152000141280220300 1680 ? S<l 0:00 /usr/bin/pulseaudio --start --log-target=syslog 1685 pts/0 Ss+ 0:00 /bin/bash 1728 ? S 0:01 /usr/lib/GConf/2/gconfd-2 1781 ? Sl 13:53 /opt/SpiderOak/lib/SpiderOak 1791 ? Ss 0:00 python /usr/bin/hp-systray -x 1801 ? S 0:00 kdeinit4: klipper [kdeinit] 1807 ? Sl 0:01 /usr/lib64/kde4/libexec/polkit-kde-authentication-agent-1 1810 ? S 1:07 python /usr/bin/hp-systray -x 1811 ? S 0:51 python /usr/bin/hp-systray -x 1815 ? Sl 0:01 /usr/bin/knotify4 1835 ? S 0:00 /usr/lib/mozilla/kmozillahelper 1839 ? Sl 243:20 /opt/SpiderOak/lib/SpiderOak --spider 1897 ? S 0:40 /opt/SpiderOak/lib/inotify_dir_watcher 1839 /home/gaf/.config/SpiderOak/config.txt /home/gaf/.config/Spider 2355 ? S 4:39 ksysguardd 2378 ? Rl 23:05 kdeinit4: konsole [kdeinit] 11758 ? Ss 7:30 ewfmount AV152_CU01C1.E01 /mnt/imageCU01 32545 pts/4 Ss 0:01 /bin/bash
===== What the hell are all those things doing with MY drive. I didn't give them permission to screw with MY drive. I use linux because it does what I tell it, not whatever it gets an urge to do. === Being ever the optimist, I tried to do a safe unmount from Dolphin, but no luck there either. I guess my only question is who I have to send the extortion money to to get my disk able to umount? === Don't expect me to respond tonight. I really am headed out of here. I really hope I did something stupid. I did try fuser --mount /dev/sdb1 and "sudo --mount /dev/sdb1". --mount changed nothing. sudo just found even more PIDs using my disk. === Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Dec 1, 2014 at 6:36 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
11758 ? Ss 7:30 ewfmount AV152_CU01C1.E01 /mnt/imageCU01
That was the culprit. I had an fuser mount in place on my external drive. After I umounted that I could umount /mnt. It still boggles my mind that fuser -m /dev/sdb1 reported have the OS had my disk in use. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/02/2014 12:47 AM, Greg Freemyer wrote:
On Mon, Dec 1, 2014 at 6:36 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
11758 ? Ss 7:30 ewfmount AV152_CU01C1.E01 /mnt/imageCU01
That was the culprit. I had an fuser mount in place on my external drive. After I umounted that I could umount /mnt.
It still boggles my mind that fuser -m /dev/sdb1 reported have the OS had my disk in use.
According to 'man fuser', you successfully listed all processes accessing files on the file system /dev: -m NAME, --mount NAME NAME specifies a file on a mounted file system or a block device that is mounted. All processes accessing files on that file system are listed. If a directory file is specified, it is automatically changed to NAME/. to use any file system that might be mounted on that directory. ;-) Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Dec 1, 2014 at 6:55 PM, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 12/02/2014 12:47 AM, Greg Freemyer wrote:
On Mon, Dec 1, 2014 at 6:36 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
11758 ? Ss 7:30 ewfmount AV152_CU01C1.E01 /mnt/imageCU01
That was the culprit. I had an fuser mount in place on my external drive. After I umounted that I could umount /mnt.
It still boggles my mind that fuser -m /dev/sdb1 reported have the OS had my disk in use.
According to 'man fuser', you successfully listed all processes accessing files on the file system /dev:
-m NAME, --mount NAME NAME specifies a file on a mounted file system or a block device that is mounted. All processes accessing files on that file system are listed. If a directory file is specified, it is automatically changed to NAME/. to use any file system that might be mounted on that directory.
;-)
Berny, We read it differently. It says "or a block device that is mounted". /dev/sdb1 was a block device that is mounted. I can't say I use use fuser -m all that often, but I'm pretty sure I have used it with a block device before. I've already unmounted the original drive, so I tried it with a different one. As you imply "fuser -m /mnt1" gives me totally different output than "fuser -m /dev/sdc1" I don't read the manual as saying it should and I don't recall them as being different when I've used fuser in the past. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-12-02 01:17, Greg Freemyer wrote:
On Mon, Dec 1, 2014 at 6:55 PM, Bernhard Voelker <> wrote:
I can't say I use use fuser -m all that often, but I'm pretty sure I have used it with a block device before.
I just tried. I plugged a usb stick, mounted it, and tried: Telcontar:~ # mount /dev/sdh1 /mnt/tmp Telcontar:~ # fuser -m /dev/sdh1 /dev/sdh1: 1 307 369 393 748 937 1025 1027 1028 1029 1033 1036 1037 1038 1039 1040 1086 1477 1480 1657 ... and several lines. But: Telcontar:~ # fuser -m /mnt/tmp Telcontar:~ # Telcontar:~ # fuser /dev/sdh1 Telcontar:~ # which is correct. Now I open a file in that stick with "less", and try again: Telcontar:~ # fuser /dev/sdh1 Telcontar:~ # lsof /dev/sdh1 lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /var/run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME less 3242 cer 4r REG 8,113 734421674 12 /mnt/tmp/Doctor.Mateo...avi Telcontar:~ # fuser -m /mnt/tmp /mnt/tmp: 3242 Telcontar:~ # See? A single process. But "fuser -m /dev/sdh1" still gives a long and incorrect list. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Mon, Dec 1, 2014 at 7:32 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2014-12-02 01:17, Greg Freemyer wrote:
On Mon, Dec 1, 2014 at 6:55 PM, Bernhard Voelker <> wrote:
I can't say I use use fuser -m all that often, but I'm pretty sure I have used it with a block device before.
I just tried. I plugged a usb stick, mounted it, and tried:
Telcontar:~ # mount /dev/sdh1 /mnt/tmp
Telcontar:~ # fuser -m /dev/sdh1 /dev/sdh1: 1 307 369 393 748 937 1025 1027 1028 1029 1033 1036 1037 1038 1039 1040 1086 1477 1480 1657 ... and several lines.
But:
Telcontar:~ # fuser -m /mnt/tmp Telcontar:~ # Telcontar:~ # fuser /dev/sdh1 Telcontar:~ #
which is correct. Now I open a file in that stick with "less", and try again:
Telcontar:~ # fuser /dev/sdh1 Telcontar:~ # lsof /dev/sdh1 lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /var/run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME less 3242 cer 4r REG 8,113 734421674 12 /mnt/tmp/Doctor.Mateo...avi Telcontar:~ # fuser -m /mnt/tmp /mnt/tmp: 3242 Telcontar:~ #
See? A single process. But "fuser -m /dev/sdh1" still gives a long and incorrect list.
Carlos, I don't know if you think it's a bug or not. I think it is. I found <http://sourceforge.net/p/psmisc/bugs/53/> which is someone reporting the same bug a few years ago, but supposedly a patch went in to fix it in version 22.20 I have version 22.21 on my 13.2 install that is having the problem. A regression? Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
problem with systemd. New Parrdin. It umounts when it wants to and tells diferent tools to report diferent things. Try killings the cgroup. If not.... well, sit and wait. Eventually the clock is always right 2x a day On Mon, Dec 01, 2014 at 07:42:42PM -0500, Greg Freemyer wrote:
On Mon, Dec 1, 2014 at 7:32 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2014-12-02 01:17, Greg Freemyer wrote:
On Mon, Dec 1, 2014 at 6:55 PM, Bernhard Voelker <> wrote:
I can't say I use use fuser -m all that often, but I'm pretty sure I have used it with a block device before.
I just tried. I plugged a usb stick, mounted it, and tried:
Telcontar:~ # mount /dev/sdh1 /mnt/tmp
Telcontar:~ # fuser -m /dev/sdh1 /dev/sdh1: 1 307 369 393 748 937 1025 1027 1028 1029 1033 1036 1037 1038 1039 1040 1086 1477 1480 1657 ... and several lines.
But:
Telcontar:~ # fuser -m /mnt/tmp Telcontar:~ # Telcontar:~ # fuser /dev/sdh1 Telcontar:~ #
which is correct. Now I open a file in that stick with "less", and try again:
Telcontar:~ # fuser /dev/sdh1 Telcontar:~ # lsof /dev/sdh1 lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /var/run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME less 3242 cer 4r REG 8,113 734421674 12 /mnt/tmp/Doctor.Mateo...avi Telcontar:~ # fuser -m /mnt/tmp /mnt/tmp: 3242 Telcontar:~ #
See? A single process. But "fuser -m /dev/sdh1" still gives a long and incorrect list.
Carlos,
I don't know if you think it's a bug or not. I think it is.
I found <http://sourceforge.net/p/psmisc/bugs/53/> which is someone reporting the same bug a few years ago, but supposedly a patch went in to fix it in version 22.20
I have version 22.21 on my 13.2 install that is having the problem.
A regression?
Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-12-02 01:42, Greg Freemyer wrote:
On Mon, Dec 1, 2014 at 7:32 PM, Carlos E. R. <> wrote:
See? A single process. But "fuser -m /dev/sdh1" still gives a long and incorrect list.
Carlos,
I don't know if you think it's a bug or not. I think it is.
+++—————————————————————————— -m NAME, --mount NAME NAME specifies a file on a mounted file system or a block device that is mounted. All processes accessing files on that file system are listed. If a directory file is specified, it is automatically changed to NAME/. to use any file system that might be mounted on that directory. ——————————————————————————++- I read that «NAME specifies a file on a mounted file system or a block device that is mounted» as meaning "a file on a mounted block device", that is, "/dev/sdh1/somefile", which is not a syntax I have seen previously. If that is not what the phrase means, well, man page writers are not universally known for easy reading, nor man page readers for understanding what the writer intended ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 02/12/14 11:03, Carlos E. R. wrote: <LINGUIST_HAT = ON>
I read that «NAME specifies a file on a mounted file system or a block device that is mounted» as meaning "a file on a mounted block device", that is, "/dev/sdh1/somefile", which is not a syntax I have seen previously.
This is definitely ambiguous... it could mean: (A) a file on [a mounted file system] or [a block device that is mounted] OR (B) [a file on a mounted file system] or [a block device that is mounted] I think, however, (A) is the intended meaning... Dx
If that is not what the phrase means, well, man page writers are not universally known for easy reading, nor man page readers for understanding what the writer intended ;-)
Writers and readers in general, it seems... Dx
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-12-02 12:13, Dylan wrote:
On 02/12/14 11:03, Carlos E. R. wrote:
<LINGUIST_HAT = ON>
I read that «NAME specifies a file on a mounted file system or a block device that is mounted» as meaning "a file on a mounted block device", that is, "/dev/sdh1/somefile", which is not a syntax I have seen previously.
This is definitely ambiguous... it could mean:
(A) a file on [a mounted file system] or [a block device that is mounted]
OR
(B) [a file on a mounted file system] or [a block device that is mounted]
I think, however, (A) is the intended meaning...
I think it means: (C) a file on a mounted filesystem, or a file on a mounted block device, because that explains what happens with the program output.
If that is not what the phrase means, well, man page writers are not universally known for easy reading, nor man page readers for understanding what the writer intended ;-)
Writers and readers in general, it seems...
Man pages are specially difficult because they use specific language. Very compact. :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 02/12/14 11:25, Carlos E. R. wrote:
On 2014-12-02 12:13, Dylan wrote:
On 02/12/14 11:03, Carlos E. R. wrote:
<LINGUIST_HAT = ON>
I read that «NAME specifies a file on a mounted file system or a block device that is mounted» as meaning "a file on a mounted block device", that is, "/dev/sdh1/somefile", which is not a syntax I have seen previously.
This is definitely ambiguous... it could mean:
(A) a file on [a mounted file system] or [a block device that is mounted]
OR
(B) [a file on a mounted file system] or [a block device that is mounted]
I think, however, (A) is the intended meaning...
I think it means:
(C) a file on a mounted filesystem, or a file on a mounted block device, because that explains what happens with the program output.
That is my (A) above... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-12-02 12:35, Dylan wrote:
On 02/12/14 11:25, Carlos E. R. wrote:
I think it means:
(C) a file on a mounted filesystem, or a file on a mounted block device, because that explains what happens with the program output.
That is my (A) above...
No, no. (A) is either (1) a file on a mounted filesystem, or, (2) a block device. I say (3) a file in a block device. It is different. (1) /mnt/somefile (2) /dev/sdXY (3) /dev/sdXY/somefile Notice that "fuser /dev/sdXY" (without -m) produces the result we want. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 02/12/14 11:44, Carlos E. R. wrote:
On 2014-12-02 12:35, Dylan wrote:
On 02/12/14 11:25, Carlos E. R. wrote:
I think it means:
(C) a file on a mounted filesystem, or a file on a mounted block device, because that explains what happens with the program output.
That is my (A) above...
No, no. (A) is either (1) a file on a mounted filesystem, or, (2) a block device. I say (3) a file in a block device. It is different.
(1) /mnt/somefile (2) /dev/sdXY (3) /dev/sdXY/somefile
Like I said: (C) = (A) = (1) OR (3) : [a file on a mounted filesystem] OR [a file on a block device which is mounted]; (B) = (1) OR (2) [a file on a mounted filesystem] OR [a block device which is mounted] -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On December 2, 2014 6:13:40 AM EST, Dylan <dylan@dylan.me.uk> wrote:
On 02/12/14 11:03, Carlos E. R. wrote:
<LINGUIST_HAT = ON>
I read that «NAME specifies a file on a mounted file system or a block device that is mounted» as meaning "a file on a mounted block device", that is, "/dev/sdh1/somefile", which is not a syntax I have seen previously.
This is definitely ambiguous... it could mean:
(A) a file on [a mounted file system] or [a block device that is mounted]
OR
(B) [a file on a mounted file system] or [a block device that is mounted]
I think, however, (A) is the intended meaning...
Dx
Bug <http://sourceforge.net/p/psmisc/bugs/53/> only makes sense if the proper interpretation is B. Note that bug was accepted and fixed, but that was a couple releases of fuser ago so a regression has crept in. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-12-02 12:58, Greg Freemyer wrote:
Bug <http://sourceforge.net/p/psmisc/bugs/53/> only makes sense if the proper interpretation is B.
Note that bug was accepted and fixed, but that was a couple releases of fuser ago so a regression has crept in.
I know, but that has me very confused. Maybe they thought that the intention was (C) and reverted the bug - no, I'm kidding you :-P -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 12/02/2014 06:13 AM, Dylan wrote:
<LINGUIST_HAT = ON>
I read that «NAME specifies a file on a mounted file system or a block device that is mounted» as meaning "a file on a mounted block device", that is, "/dev/sdh1/somefile", which is not a syntax I have seen previously.
This is definitely ambiguous... it could mean:
(A) a file on [a mounted file system] or [a block device that is mounted]
OR
(B) [a file on a mounted file system] or [a block device that is mounted]
I think, however, (A) is the intended meaning...
I agree with your interpretation. At a meeting just this last week I made a similar criticism of the sloppy language of a item in a status report and was surprised when some other attendees turned on me, telling me that it didn't matter and that "this wasn't the place for a lecture on English grammar" Of course coming from engineering I do know that imprecise statements can result in catastrophes and can be life threatening. We take it that this isn't, but who knows? "For want of a nail..." many situations have only so much time, energy and attention-span. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi Greg, On 12/02/2014 01:17 AM, Greg Freemyer wrote:
We read it differently. It says "or a block device that is mounted".
you're right. However, fuser doesn't seem to detect that the argument is a mount point - see the -M option, e.g. $ findmnt --source /dev/sdc2 TARGET SOURCE FSTYPE OPTIONS /os131 /dev/sdc2 ext4 ro,noatime,data=ordered $ fuser -mM /dev/sdc2 Specified filename /dev/sdc2 is not a mountpoint. $ fuser -m /dev/sdc2 /dev/sdc2: 1rce 2rc 3rc 5rc 7rc 8rc 9rc 10rc 11rc 12rc 13rc 14rc 15rc 16rc 17rc 18rc 19rc 20rc 21rc 22rc 23rc 25rc 26rc 27rc 28rc 29rc 30rc 31rc 32rc 33rc 34rc 35rc 36rc 37rc 38rc 41rc 42rc 49rc 50rc 51rc 52rc ... Using strace, I see that fuser reads both /proc/self/mountinfo and /proc/mounts, which both have the correct information there. Therefore, and without having looked into the sources, I'd consider this a bug. Would you like to file one? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/14 08:33, Bernhard Voelker wrote:
Hi Greg,
On 12/02/2014 01:17 AM, Greg Freemyer wrote:
We read it differently. It says "or a block device that is mounted".
you're right. However, fuser doesn't seem to detect that the argument is a mount point - see the -M option, e.g.
But (below) /dev/sdc2 isn't the mountpoint... /os131 is...
$ findmnt --source /dev/sdc2 TARGET SOURCE FSTYPE OPTIONS /os131 /dev/sdc2 ext4 ro,noatime,data=ordered
$ fuser -mM /dev/sdc2 Specified filename /dev/sdc2 is not a mountpoint.
$ fuser -m /dev/sdc2 /dev/sdc2: 1rce 2rc 3rc 5rc 7rc 8rc 9rc 10rc 11rc 12rc 13rc 14rc 15rc 16rc 17rc 18rc 19rc 20rc 21rc 22rc 23rc 25rc 26rc 27rc 28rc 29rc 30rc 31rc 32rc 33rc 34rc 35rc 36rc 37rc 38rc 41rc 42rc 49rc 50rc 51rc 52rc ...
Using strace, I see that fuser reads both /proc/self/mountinfo and /proc/mounts, which both have the correct information there. Therefore, and without having looked into the sources, I'd consider this a bug. Would you like to file one?
Have a nice day, Berny
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/02/2014 09:46 AM, Dylan wrote:
On 02/12/14 08:33, Bernhard Voelker wrote:
Hi Greg,
On 12/02/2014 01:17 AM, Greg Freemyer wrote:
We read it differently. It says "or a block device that is mounted".
you're right. However, fuser doesn't seem to detect that the argument is a mount point - see the -M option, e.g.
But (below) /dev/sdc2 isn't the mountpoint... /os131 is...
ah, sorry: s/is a mount point/is a mounted block device/ Here's the counter example with the mount point: $ fuser -m /os131 $ fuser -mM /os131 No processes (which is correct), and the mount point detection works. ;-)
$ findmnt --source /dev/sdc2 TARGET SOURCE FSTYPE OPTIONS /os131 /dev/sdc2 ext4 ro,noatime,data=ordered
$ fuser -mM /dev/sdc2 Specified filename /dev/sdc2 is not a mountpoint.
$ fuser -m /dev/sdc2 /dev/sdc2: 1rce 2rc 3rc 5rc 7rc 8rc 9rc 10rc 11rc 12rc 13rc 14rc 15rc 16rc 17rc 18rc 19rc 20rc 21rc 22rc 23rc 25rc 26rc 27rc 28rc 29rc 30rc 31rc 32rc 33rc 34rc 35rc 36rc 37rc 38rc 41rc 42rc 49rc 50rc 51rc 52rc ...
Using strace, I see that fuser reads both /proc/self/mountinfo and /proc/mounts, which both have the correct information there. Therefore, and without having looked into the sources, I'd consider this a bug. Would you like to file one?
Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Dec 2, 2014 at 11:33 AM, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
Hi Greg,
On 12/02/2014 01:17 AM, Greg Freemyer wrote:
We read it differently. It says "or a block device that is mounted".
you're right. However, fuser doesn't seem to detect that the argument is a mount point - see the -M option, e.g.
"mount point" means directory where block device is mounted on. Now with block device ... as extreme example mknod /dev/foo b MM mm mknod /dev/bar b MM mm (same MM and same mm) mount /dev/foo /mnt Is /dev/bar now to be considered mounted or not? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On December 2, 2014 3:33:54 AM EST, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
Hi Greg,
On 12/02/2014 01:17 AM, Greg Freemyer wrote:
We read it differently. It says "or a block device that is mounted".
you're right. However, fuser doesn't seem to detect that the argument is a mount point - see the -M option, e.g.
$ findmnt --source /dev/sdc2 TARGET SOURCE FSTYPE OPTIONS /os131 /dev/sdc2 ext4 ro,noatime,data=ordered
$ fuser -mM /dev/sdc2 Specified filename /dev/sdc2 is not a mountpoint.
$ fuser -m /dev/sdc2 /dev/sdc2: 1rce 2rc 3rc 5rc 7rc 8rc 9rc 10rc 11rc 12rc 13rc 14rc 15rc 16rc 17rc 18rc 19rc 20rc 21rc 22rc 23rc 25rc 26rc 27rc 28rc 29rc 30rc 31rc 32rc 33rc 34rc 35rc 36rc 37rc 38rc 41rc 42rc 49rc 50rc 51rc 52rc ...
Using strace, I see that fuser reads both /proc/self/mountinfo and /proc/mounts, which both have the correct information there. Therefore, and without having looked into the sources, I'd consider this a bug. Would you like to file one?
At opensuse? Upstream? Both?
Have a nice day, Berny
Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/02/2014 12:59 PM, Greg Freemyer wrote:
On December 2, 2014 3:33:54 AM EST, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
Using strace, I see that fuser reads both /proc/self/mountinfo and /proc/mounts, which both have the correct information there. Therefore, and without having looked into the sources, I'd consider this a bug. Would you like to file one?
At opensuse? Upstream? Both?
Having a quic k glance at the patches in https://build.opensuse.org/package/show/Base:System/psmisc ... I think they're invasive enough that the bug is possibly only there rather than upstream. Of course you could try to './configure && make all install' the upstream version yourself to see if the bug is there, too. ;-) Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Dec 2, 2014 at 11:09 AM, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 12/02/2014 12:59 PM, Greg Freemyer wrote:
On December 2, 2014 3:33:54 AM EST, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
Using strace, I see that fuser reads both /proc/self/mountinfo and /proc/mounts, which both have the correct information there. Therefore, and without having looked into the sources, I'd consider this a bug. Would you like to file one?
At opensuse? Upstream? Both?
Having a quic k glance at the patches in https://build.opensuse.org/package/show/Base:System/psmisc ... I think they're invasive enough that the bug is possibly only there rather than upstream.
Of course you could try to './configure && make all install' the upstream version yourself to see if the bug is there, too. ;-)
Have a nice day, Berny
Both upstream and openSUSE versions fail to work right, but in different ways. Details in <https://bugzilla.opensuse.org/show_bug.cgi?id=908068> Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-12-02 00:55, Bernhard Voelker wrote:
According to 'man fuser', you successfully listed all processes accessing files on the file system /dev:
:-) Good catch. I'm more familiar with lsof than with fuser, so I thought that was the normal ussage. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-12-02 00:36, Greg Freemyer wrote:
What the hell are all those things doing with MY drive. I didn't give them permission to screw with MY drive.
It looks like your home. Wild guess: did you use "startx"? If you did, was your current directory that "/mnt"?
I guess my only question is who I have to send the extortion money to to get my disk able to umount?
You could try "umount --lazy /mnt &". In emergencies, it works. At least, it impedes anything else opening any file in there, and they eventually have to drop the files they have; and when they do, they can not pick any new file in there. Some can not stand the idea and die of grief and hurt, complaining loudly. :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (7)
-
Andrei Borzenkov -
Anton Aylward -
Bernhard Voelker -
Carlos E. R. -
Dylan -
Greg Freemyer -
Ruben Safir