Slackware Current Mounting Partitions

[Jimmy Johnson]

I'm having to logout and back in to unmount partitions, I've never had
to that before. On some other systems I can expect things like that to
happen, but not slackware.
--
Jimmy Johnson

AntiX - AMD A8-7600 - EXT4 at sda12
Registered Linux User #380263

[Ralph Spitzner]

Jimmy Johnson wrote on 4/10/21 6:59 PM:

> I'm having to logout and back in to unmount partitions, I've never had to that before. On some other systems I can expect things like that to happen, but not slackware.

Your bash might me "sitting on it" :-) try cd'ing somewhere neutral, before umounting....
Anyway you left open the most interesting part:
what does umount say when it refuses to umount ?

-rasp

[Henrik Carlqvist]

It is possible to list processing having open files or directories on a
mounted file system, a command like:

fuser -c /home

Will list the PIDs of those processes.

regards Henrik

[Jimmy Johnson]

It say's it's busy..I uses kde and konsole, nothing was open, looking at
ksysguard showed me nothing I can point at that would keep a file
manager active or lock a partition, it's just a partition I share with
many other installed systems, very little personal stuff is on any of my
systems I use other unmounted partitions and set them up in fstab for
quick access for more than 25yrs. It's happened after watching a movie
on another partition and it's happened after coping a text file from a
flash drive to another partition. It may have something to do with these
new kernels and probably something slackware will fix if they can.

[Jimmy Johnson]

On 04/10/2021 11:03 AM, Henrik Carlqvist wrote:

> It is possible to list processing having open files or directories on a
> mounted file system, a command like:
>
> fuser -c /home
>
> Will list the PIDs of those processes.

Thanks, and will do the next time it happens.

[Ralph Spitzner]

Jimmy Johnson wrote on 4/10/21 9:43 PM:

> On 04/10/2021 10:28 AM, Ralph Spitzner wrote:

> after watching a movie on another partition and it's happened after coping a text file from a flash drive to another partition. It may have something to do with these new kernels and probably something slackware will fix if they can.

I'm pretty sure its not a kernel thing.
Some proccess is holding it 'hostage'.
in addition to what henrik said you can also try:
lsof | grep <yourmountpoint>
to find the pid......

-rasp

[m...@asd.home]

On 2021-04-10, Jimmy Johnson <ji...@none.none> wrote:
> I'm having to logout and back in to unmount partitions, I've never had
> to that before. On some other systems I can expect things like that to
> happen, but not slackware.

There is a tool called iotop that might give you a clue about which
processes are doing disk i/o, there is a slackbuild for it.

[m...@asd.home]

On 2021-04-10, Jimmy Johnson <ji...@none.none> wrote:

> I'm having to logout and back in to unmount partitions, I've never had
> to that before. On some other systems I can expect things like that to
> happen, but not slackware.

Another option is to try fuser -v to list which processes have files
open on the mount point.

[Jimmy Johnson]

Now that one I did do, and it showed nothing.

[Jimmy Johnson]

On 04/10/2021 03:41 PM, m...@asd.home wrote:

> Another option is to try fuser -v

Is that it, just 'fuser -v'

[m...@asd.home]

On 2021-04-10, Jimmy Johnson <ji...@none.none> wrote:

> On 04/10/2021 03:41 PM, m...@asd.home wrote:
>
>> Another option is to try fuser -v
>
> Is that it, just 'fuser -v'

You need fuser -v <mountpoint>

so for example
fuser -v /home
will show all pids that have files open on the filesystem mounted on
/home

[Jimmy Johnson]

On 04/10/2021 01:48 PM, Ralph Spitzner wrote:

> Jimmy Johnson wrote on 4/10/21 9:43 PM:
>> On 04/10/2021 10:28 AM, Ralph Spitzner wrote:
>
>> after watching a movie on another partition and it's happened after
>> coping a text file from a flash drive to another partition. It may
>> have something to do with these new kernels and probably something
>> slackware will fix if they can.
>
> I'm pretty sure its not a kernel thing.

PCLinuxOS, a rolling distro is using the same version kde and the same
kernel as slackware current and it is giving me the same problems, so if
it's not the kernel then it has to be kde, I suppose. Like I said, I
will run any suggested test when it happens again. That's what I do is
test stuff, I tested for kde and debian for more than 20yrs, but no
longer since systemd and with debian covering up problems caused by
systemd. I'll be setting up blacklist on 4 systems maybe the umount
problem will popup. Okay, I just got "Called: umount /dev/sdb2 umount:
/home/jimmy/01-SDB target is busy." And I will run test now.
--
Jimmy Johnson

Slackware64 Current - AMD A8-7600 - EXT4 at sda6
Registered Linux User #380263

[Jimmy Johnson]

On 4/11/21 10:17 AM, Jimmy Johnson wrote:

> Okay, I just got "Called: umount /dev/sdb2 umount:
> /home/jimmy/01-SDB target is busy." And I will run test now.

jimmy@LATITUDE:~$ fuser -c /home
/home: 1552rce 1553rce 1561rce 1562rce 1586rce 1587rce
1600rce 1604rce 1608rce 1622rce 1626rce 1635rce 1638rce 1647rce
1658rce 1670rce 1683rce 1692rce 1694rce 1701rce 1718rce 1752rce
1778rce 1882rce 1906rce 2055rce 2066rce 2117rce 2122rce 2147rce
2570rce 2660rce 2671rce 2677rce 2682rce 2686rce 2695rce 2711rce

The above mean nothing to me, can someone explain whats going on.

Both
jimmy@LATITUDE:~$ fuser -v /home and
jimmy@LATITUDE:~$ fuser -v /dev/sdb2
Say nothing.

jimmy@LATITUDE:~$ fuser -c /dev/sdb2
/dev/sdb2: 1906

jimmy@LATITUDE:~$ fuser -mu /dev/sdb2
/dev/sdb2: 1906(jimmy)

None of this helps me, I still don't know what's going on.
--
Jimmy Johnson

Slackware64 Current - KDE 4.14.38 - Intel i7-3540M - EXT4 at sda6
Registered Linux User #380263

[Øyvind Røtvold]

Jimmy Johnson <field.e...@gmail.com> writes:

> On 4/11/21 10:17 AM, Jimmy Johnson wrote:
>
>> Okay, I just got "Called: umount /dev/sdb2 umount:
>> /home/jimmy/01-SDB target is busy." And I will run test now.
>
> jimmy@LATITUDE:~$ fuser -c /home

/home is probably not relevant here.

[...]

>
> The above mean nothing to me, can someone explain whats going on.
>
> Both
> jimmy@LATITUDE:~$ fuser -v /home and
> jimmy@LATITUDE:~$ fuser -v /dev/sdb2

You need to run fuser on the mount point, not on the /dev/sdb2 wich
(probably) is the device.

use:
$ df | fgrep /dev/sdb2
to find the mount point.

[ ... ]

--
.. Ųyvind - soon to appear in a kill file near you.
.. Ignorance can be cured; stupidity is forever.

[Jimmy Johnson]

On 04/11/2021 01:40 PM, Øyvind Røtvold wrote:

> You need to run fuser on the mount point, not on the /dev/sdb2 wich
> (probably) is the device.

Just to be clear, if I'm watching at '/home/jimmy/01-SDB/01-My
Movies/Young Guns - 1 - [1988]/' that would be the mount point?

I had been watching a movie using "dragon player" when it happened,
using qtav player it did not happen.

> use:
> $ df | fgrep /dev/sdb2
> to find the mount point.
>
> [ ... ]

The computer for these tests is busy now transcoding a movie, I'll have
to get back to this later and then I will run the above test.
--
Jimmy Johnson

Slackware64 Current - AMD A8-7600 - EXT4 at sda6
Registered Linux User #380263

[Ralph Spitzner]

/home/jimmy/01-SDB/
probably is your mount point
you can see this by running 'mount' without arguments......

-rasp

[Jimmy Johnson]

On 04/11/2021 08:17 PM, Jimmy Johnson wrote:
> On 04/11/2021 01:40 PM, Øyvind Røtvold wrote:
>
>> You need to run fuser on the mount point, not on the /dev/sdb2 wich
>> (probably) is the device.
>
> Just to be clear, if I'm watching at '/home/jimmy/01-SDB/01-My
> Movies/Young Guns - 1 - [1988]/' that would be the mount point?
>
> I had been watching a movie using "dragon player" when it happened,
> using qtav player it did not happen.
>
>> use:
>> $ df | fgrep /dev/sdb2
>> to find the mount point.
>>
>> [ ... ]
>
> The computer for these tests is busy now transcoding a movie, I'll have
> to get back to this later and then I will run the above test.

I think I found the problem, I changed a "startup setting" in dolphin to
use the fixed location /home/jimmy. And now I can't reproduce the umount
problem.

Thanks for the input, in a way you helped me keep at it until I found
the problem.

Apparently saving "folders, tabs, and window state from last time" was
causing the problem and that now seems to be the default setting and the
reason for the problem.

[Rich]

Jimmy Johnson <ji...@none.none> wrote:

> On 04/11/2021 01:40 PM, Řyvind Rřtvold wrote:
>
>> You need to run fuser on the mount point, not on the /dev/sdb2 wich
>> (probably) is the device.
>
> Just to be clear, if I'm watching at '/home/jimmy/01-SDB/01-My
> Movies/Young Guns - 1 - [1988]/' that would be the mount point?

No. A mount point is the directory on top of which is mounted a
filesystem from a device.

So if you have this:

mount /dev/sda3 /home

Then /home is a "mountpoint", because the filesystem in the partition
at /dev/sda3 is mounted on /home.

[Jimmy Johnson]

Wrong again. :( While working with blacklist, updating and installing
packages successfully, no problems there. My slackware packages are on
/home/jimmy/01-SDA, I was unable to umount as user or root - device is
busy!!

jimmy@PAVILION:~$ df | fgrep /home/jimmy/01-SDA
/dev/sda13 80266056 65661928 10503728 87% /home/jimmy/01-SDA

jimmy@PAVILION:~$ df | fgrep /dev/sda13
/dev/sda13 80266056 65661928 10503728 87% /home/jimmy/01-SDA

I ran the above as root to and got the same output and those numbers
mean nothing to me. I now need to logout to umount the partition. Later...

[Jimmy Johnson]

Logging out and then back in the partition is still mounted, but I can
now umount. But I still don't know whats causing it to lockup? I should
not need to logout to umount a partition. This is getting a bit irratating.

[Lew Pitcher]

On Mon, 12 Apr 2021 18:27:20 +0000, Larry wrote:

> On Mon, 12 Apr 2021 07:27:55 -0700, Jimmy Johnson <ji...@none.none>
> wrote:
[snip]

>>jimmy@LATITUDE:~$ fuser -c /home /home: 1552rce 1553rce
>>1561rce 1562rce 1586rce 1587rce 1600rce 1604rce 1608rce 1622rce
>>1626rce 1635rce 1638rce 1647rce 1658rce 1670rce 1683rce 1692rce
>>1694rce 1701rce 1718rce 1752rce 1778rce 1882rce 1906rce 2055rce
>>2066rce 2117rce 2122rce 2147rce 2570rce 2660rce 2671rce 2677rce
>>2682rce 2686rce 2695rce 2711rce
>

> The numbers are the PID (process ID) of the processes running/using
> /home. Not sure what the "rce" signifies!

fuser(1) ("man 1 fuser") says that:
fuser displays the PIDs of processes using the specified files or file
systems. In the default display mode, each file name is followed by a
letter denoting the type of access:
c current directory.
e executable being run.
f open file. f is omitted in default display mode.
F open file for writing. F is omitted in default display mode.
r root directory.
m mmap'ed file or shared library.

Thus, the "rce" appended to each PID means that the PID
- has /home as it's root directory ("r"),
- has /home as it's current working directory ("c")
- has execution access to /home
(? I'm not sure if this is the correct interpretation)

[snip]
--
Lew Pitcher
"In Skills, We Trust"

[Jimmy Johnson]

On 4/12/21 11:27 AM, Larry wrote:

fuser -c gave me pid 9228 - I searched ksysguard and found 'file.so' and
killed it and was able to umount.

> It may be simpler/easier to log out and log back in, depending on how
> many processes are using the partition.

It's less stress that's for sure. :)
--
Jimmy Johnson

Slackware64 Current - KDE 4.14.38 - Intel i7-3540M - EXT4 at sda6
Registered Linux User #380263

[Henrik Carlqvist]

On Sun, 11 Apr 2021 10:58:53 -0700, Jimmy Johnson wrote:

> On 4/11/21 10:17 AM, Jimmy Johnson wrote:
>
>> Okay, I just got "Called: umount /dev/sdb2 umount: /home/jimmy/01-SDB
>> target is busy." And I will run test now.
>
> jimmy@LATITUDE:~$ fuser -c /home /home: 1552rce 1553rce
> 1561rce 1562rce 1586rce 1587rce 1600rce 1604rce 1608rce 1622rce
> 1626rce 1635rce 1638rce 1647rce 1658rce 1670rce 1683rce 1692rce
> 1694rce 1701rce 1718rce 1752rce 1778rce 1882rce 1906rce 2055rce
> 2066rce 2117rce 2122rce 2147rce 2570rce 2660rce 2671rce 2677rce
> 2682rce 2686rce 2695rce 2711rce
>
> The above mean nothing to me, can someone explain whats going on.

As you have trouble unmounting the directory /home/jimmy/01-SDB you
should try running fuser on that directory:

fuser -c /home/jimmy/01-SDB

The above command will list the process ID of every process occupying
that directory. By killing those processes the directory will no longer
be busy and you will be able to unmount the directory.

regards Henrik

[Jimmy Johnson]

On 4/12/21 11:28 PM, Henrik Carlqvist wrote:

> As you have trouble unmounting the directory /home/jimmy/01-SDB you
> should try running fuser on that directory:
>
> fuser -c /home/jimmy/01-SDB
>
> The above command will list the process ID of every process occupying
> that directory. By killing those processes the directory will no longer
> be busy and you will be able to unmount the directory.

Thanks Henrik, with your post and the others, as I posted above it was
'file.so' that was locking things up, I killed it and was able to
umount. It's a problem I hope gets fixed before release.

Thanks again,
--
Jimmy Johnson

Slackware64 Current - AMD A8-7600 - EXT4 at sda7
Registered Linux User #380263

[Ralph Spitzner]

Jimmy Johnson wrote on 4/13/21 1:40 PM:

It's a problem I hope gets fixed before release.
>
> Thanks again,

file.so belongs to baloo (file indexing kde[plasma]).
a quick google reveals:
Hi, did you try to disable baloo under system settings->search-> configuration and disable archive search (the application is called baloo)

so it's a kde problem....
-rasp

[Jimmy Johnson]

I renamed it and it broke dolphin with.
Unable to create io-slave. klauncher said: Could not find the
'/usr/lib64/qt5/plugins/kf5/kio/file.so' plugin.

kde is saying they fixed it last month..

[Aragorn]

On 13.04.2021 at 10:42, Jimmy Johnson scribbled:

> On 4/13/21 9:58 AM, Ralph Spitzner wrote:
> > Jimmy Johnson wrote on 4/13/21 1:40 PM:
> > It's a problem I hope gets fixed before release.
> >>
> >> Thanks again,
> >
> > file.so belongs to baloo (file indexing kde[plasma]).
> > a quick google reveals:
> > Hi, did you try to disable baloo under system settings->search->
> > configuration and disable archive search (the application is called
> > baloo)
> >
> > so it's a kde problem....
> >    -rasp
>
> I renamed it and it broke dolphin with.
> Unable to create io-slave. klauncher said: Could not find the
> '/usr/lib64/qt5/plugins/kf5/kio/file.so' plugin.

Of course it did. What did you expect? Try renaming /etc/shadow and
see what that would lead to. <facepalm>

You cannot just go and rename components of the system without breaking
anything.

> kde is saying they fixed it last month..

You can tell Baloo to not index certain directories or filesystems.


System Settings
→ Workspace
→ → Search
→ → → File Search → Folder-specific configuration


--
With respect,
= Aragorn =

[Jimmy Johnson]

On 04/13/2021 10:57 AM, Aragorn wrote:

> You can tell Baloo to not index certain directories or filesystems.
>
>
> System Settings
> → Workspace
> → → Search
> → → → File Search → Folder-specific configuration

If you where using slackware you could test it yourself.

[Aragorn]

On 13.04.2021 at 11:30, Jimmy Johnson scribbled:

> On 04/13/2021 10:57 AM, Aragorn wrote:
>
> > You can tell Baloo to not index certain directories or filesystems.
> >
> > System Settings
> > → Workspace
> > → → Search
> > → → → File Search → Folder-specific configuration
>
> If you where using slackware you could test it yourself.

I'm not using Slackware; I'm using Manjaro, and I'm running KDE
Plasma 5.21.3.

Nevertheless, my comments stand, i.e.:

1. If you rename a system component, you will get breakage.

2. You can exclude certain directories and filesystems from being
indexed by Baloo, just as you can disable Baloo's indexing
altogether.

As an example, I make backups with Timeshift, and the backups are
stored on a dedicated partition on a HDD — my system itself is
installed on an SSD.

Timeshift automatically mounts the partition with the backups whenever
I start it, but I have to manually unmount the partition again after the
backup process has finished. Baloo hives me no problems in that regard,
because I've told it not to index the contents of the partition with
the backups.

[Jimmy Johnson]

On 4/13/21 9:58 AM, Ralph Spitzner wrote:

Did you find the Bug 434455
Summary: kinit doesn't terminate "file.so" and the partition cannot be
unmounted. https://bugs.kde.org/show_bug.cgi?id=434455


If you keep looking, follow links you learn it's a hook and a
undisclosed blob that was pushed into the kde desktop via kde cia:
# Generate the non-variant part of the XML message sent to CIA.
name = E.name("KDE CIA Python client")
version = E.version("1.00")

https://invent.kde.org/sysadmin/repo-management/-/blob/master/hooks/hooklib.py#L875


A big problem with turning off services is that they can be turned on
again, it least until 15 goes final. But hooks like this don't belong in
my system. The hook needs to be permanently turned off or removed.

I went thru all my service and turned off many, thank you, but from what
I read this is a kinit thing and can only be configured while compiling
kinit.
--
Jimmy Johnson

PCLinuxOS - AMD A8-7600 - EXT4 at sda8
Registered Linux User #380263

[Jimmy Johnson]

Major upgrade, fix much regression, I ran some test and got no partition
lockup and hope it will not happen again, that's the good news. The bad
news is 'file.so' is still running, it's just no longer causing
regression. Slackware is doing better than PCLOS, they have 2 'file.so',
there second one has something to do with video in the /user
tree.Thanks, I'm going to call this fixed.

[Jimmy Johnson]

Searching *file.so = 25 items found on current kde plasma, search other
systems not slackware and you can find even more.
--
Jimmy Johnson

Slackware64 Current - Intel i7-3540M - EXT4 at sda7
Registered Linux User #380263