On 12/02/2014 12:47 AM, Greg Freemyer wrote:

On Mon, Dec 1, 2014 at 6:36 PM, Greg Freemyer 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 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)

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. 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 02/12/14 11:03, Carlos E. R. wrote:

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 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:

...

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 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 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)

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 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 December 2, 2014 3:33:54 AM EST, 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.

$ 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 Tue, Dec 2, 2014 at 11:09 AM, Bernhard Voelker wrote:

On 12/02/2014 12:59 PM, Greg Freemyer wrote:

...

On December 2, 2014 3:33:54 AM EST, Bernhard Voelker 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