All Things KDE5/Plasma for Slackware Users.

marav · 07-22-2021, 06:55 AM

Would this patch have a reason to exist if slackware was FHS compliant and we had /var/run as a symbolic link to /run?

even if the question doesn't really matter anymore, since the patch has been applied upstream

j12i · 07-22-2021, 07:10 AM

I wouldn't say it's sure the patch lands in the next version of solid just because someone wrote the code. Otoh there's really no reason to leave this check out...

marav · 07-22-2021, 07:16 AM

I understand. Thank you.

LuckyCyborg · 07-22-2021, 07:17 AM

Quote:

Originally Posted by pchristy

Has anyone notified Patrick of any of this - including the various patches? Surely this is something he should be involved in since (to me!) it appears to address fundamental Slackware practices.

I know he does keep an eye on this forum, but this problem is "hidden" under a thread name that does not flag up its importance.

If no-one else wishes to, I will contact him, but it would be better coming from someone like LuckyCyborg, as he seems to have his finger well and truly on the pulse of this, as well as having found a solution to the problem.

Just my 2p worth!

--
Pete

While in the last years usually I had no fear or remorse to argue worth of 10 pages with the Scholars hanging in this forum, regarding even a single "comma" on the Slackware Gospels, this time I have no disposition to quarrel with them on the Requests Thread - specially after reading this:

Quote:

Originally Posted by notzed

It's these pithy, ego-driven, over-confident, condescending, and completely unhelpful comments like yours and some others around here (luckycyborg springs to mind) that makes internet forums like these such a winner for new and old users alike. So damn unnecessary too, maybe you should've spent more of those 20+ years learning some netiquette and basic manners.

So, feel free to lead and raise this FHS conformance issue, if you believe on it.

LuckyCyborg · 07-22-2021, 07:34 AM

Quote:

Originally Posted by j12i

I wouldn't say it's sure the patch lands in the next version of solid just because someone wrote the code.

Well, looks like it certainly will be part of the next Solid release, because it was merged.

https://invent.kde.org/frameworks/so...ge_requests/48

And guess what?

Who thought that they will think that's better to patch also KIO, just in case?

https://invent.kde.org/frameworks/ki...6acf6b49f004f9

igadoter · 07-22-2021, 07:39 AM

Quote:

Originally Posted by LuckyCyborg

This is what the end of /proc/self/mountinfo looks on openSUSE Tumbleweed with an USB drive mounted via Dolphin:

Code:

724 29 0:43 / /run/user/0 rw,nosuid,nodev,relatime shared:371 - tmpfs tmpfs rw,size=1630728k,nr_inodes=407682,mode=700,inode64
808 724 0:45 / /run/user/0/gvfs rw,nosuid,nodev,relatime shared:434 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=0,group_id=0
842 29 8:49 / /run/media/root/ADATA\040UFD rw,nosuid,nodev,relatime shared:461 - vfat /dev/sdd1 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro

This is what the end of /proc/self/mountinfo looks on Slackware-current with an USB drive mounted via Dolphin:

Code:

53 24 0:44 / /run/user/0 rw,nosuid,nodev,relatime shared:2 - tmpfs tmpfs rw,size=1632440k,nr_inodes=408110,mode=700,inode64
54 49 0:44 / /var/run/user/0 rw,nosuid,nodev,relatime shared:2 - tmpfs tmpfs rw,size=1632440k,nr_inodes=408110,mode=700,inode64
55 53 0:45 / /run/user/0/gvfs rw,nosuid,nodev,relatime shared:3 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=0,group_id=0
56 54 0:45 / /var/run/user/0/gvfs rw,nosuid,nodev,relatime shared:3 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=0,group_id=0
68 24 8:49 / /run/media/root/ADATA\040UFD rw,nosuid,nodev,relatime shared:4 - vfat /dev/sdd1 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro
69 49 8:49 / /var/run/media/root/ADATA\040UFD rw,nosuid,nodev,relatime shared:4 - vfat /dev/sdd1 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro

So, on openSUSE the USB drive is mounted on /run/media/root/ADATA\040UFD while on Slackware is "mounted" on /run/media/root/ADATA\040UFD and /var/run/media/root/ADATA\040UFD

How did you get those listings?

marav · 07-22-2021, 07:43 AM

Code:

cat /proc/self/mountinfo

LuckyCyborg · 07-22-2021, 07:45 AM

Quote:

Originally Posted by igadoter

How did you get those listings?

Doing on both openSUSE Tumbleweed and Slackware running systems the following command:

Code:

cat /proc/self/mountinfo > ~/mountinfo.txt

igadoter · 07-22-2021, 07:45 AM

Gotcha.

Code:

$ ldd  /usr/bin/cat
	linux-vdso.so.1 (0x00007ffd20b6a000)
	libc.so.6 => /lib64/libc.so.6 (0x00007febd7d81000)
	/lib64/ld-linux-x86-64.so.2 (0x00007febd7f92000)

do you see libmount here?

LuckyCyborg · 07-22-2021, 07:48 AM

Quote:

Originally Posted by igadoter

Gotcha.

Code:

$ ldd  /usr/bin/cat
	linux-vdso.so.1 (0x00007ffd20b6a000)
	libc.so.6 => /lib64/libc.so.6 (0x00007febd7d81000)
	/lib64/ld-linux-x86-64.so.2 (0x00007febd7f92000)

do you see libmount here?

/usr/bin/cat is not linked against libmount and probably never was.

What is the sense of this question?

pchristy · 07-22-2021, 07:49 AM

Quote:

Originally Posted by LuckyCyborg

While in the last years usually I had no fear or remorse to argue worth of 10 pages with the Scholars hanging in this forum, regarding even a single "comma" on the Slackware Gospels, this time I have no disposition to quarrel with them on the Requests Thread - specially after reading this:

So, feel free to lead and raise this FHS conformance issue, if you believe on it.

I seriously doubt that I'm qualified to comment on FHS conformance!

However, I can understand your feelings regarding forum comments! In this case, though, you have been spot-on with your diagnosis and fix, and that alone should be enough to put many of the "scholars" in their place!

Actions speak louder than words!

I was on the receiving end of some smart-alec comments from someone on the slackware-arm forum when I warned about this issue there, having had it on my Raspberry Pi-400 (slarm64) too. The person in question had clearly not read thoroughly my post on the matter, and quickly went away when this was pointed out.

These forums are a gold-mine of information and help, and while I make no claims to be a programming expert, I can follow "C" code - though not necessarily write it - and do simple patches. Sometimes things come up that I have experienced and found a fix for. If I can help, I will. If someone wishes to slag me off for that, than I regard it as their problem not mine!

I wish you well, whoever you are and thank you for your time and effort here.

UPDATE: comment posted in "Requests for -current" thread.

Regards,

--
Pete

igadoter · 07-22-2021, 08:03 AM

Quote:

Originally Posted by LuckyCyborg

/usr/bin/cat is not linked against libmount and probably never was.

What is the sense of this question?

/proc/self is populated for calling process. To me it means two processes can see different /proc/self/mountinfo. KDE is using libmount - not direct system call. More informative would be to compare eg. output of df - as df is using libmount.

Edit: Perhaps KDE programmer tried to achieve what is in df output. You don't see /var/run entries.

bassmadrigal · 07-22-2021, 12:21 PM

Quote:

Originally Posted by igadoter

Can someone explain this? Say I can access directly /run, I can access directly /var/run - but not both!? Or perhaps this means program has to use interface to access /run and /var/run?

I think it is down to the program itself. It should either use /var/run/ or /run/. It shouldn't have one part of the program that uses /var/run and another part that uses /var/.

Quote:

Originally Posted by marav

Would this patch have a reason to exist if slackware was FHS compliant and we had /var/run as a symbolic link to /run?

I'm not sure Slackware is breaking FHS compliance in regard to /var/run/, however, there's a lot of the FHS that can be up for interpretation (see /usr/ vs /usr/local/ for things like SBo packages -- there's been mounds of discussions on that in the forum over time).

Here's what it says:

Quote:

It is valid to implement /var/run as a symlink to /run.

It only says it's "valid", not "required". To me, in this instance valid is another word for "acceptable".

If we compare this to two other lines:

Quote:

Configuration files for boot loaders that are not required at boot time must be placed in /etc.
--snip--
The following directories, or symbolic links to directories, are required in /var:

Note that they use "required" and "must". Based on this, it seems that the symlink is optional based on the FHS.

ZhaoLin1457 · 07-22-2021, 01:47 PM

Quote:

Originally Posted by bassmadrigal

Based on this, it seems that the symlink is optional based on the FHS.

Yes, according with FHS 3.0 the /var/run should be a directory or a symlink to /run

But, is written somewhere that a /var/run directory should be mounted as shared bind with /run ?

Meaning by "shared bind" the ability that a mountpoint within /run to be present on /var/run and a device to appear as being multiple times mounted for the system, just like appears for Solid.

I discussed with some friends of mine who are also Linux users, and everybody agreed that in the letter of FHS specs that means either separate directories, either a symlink of /var/run to /run .

You do not think is that strange that certified RHEL system administrators, who handles hundreds of mission critical servers as job, but nobody of them heard about doing this shared bind thing for run directories?

And everybody agreed with one thing: this shared bind mounting means troubles, because it may confuse various programs.

USUARIONUEVO · 07-22-2021, 02:39 PM

History with happy end , im happy seeying how community can work to solve a problem.