LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   How to explain the usefulness of /run to mere mortals? (https://www.linuxquestions.org/questions/slackware-14/how-to-explain-the-usefulness-of-run-to-mere-mortals-4175439094/)

kikinovak 11-28-2012 04:36 AM

How to explain the usefulness of /run to mere mortals?
 
Hi,

Until recently, I could explain Linux mount points more or less simply to students. /mnt being the traditional mount point, with a series of preconfigured mount point directories in Slackware that you are free to use when working in console mode on a server, for example. And then /media, useful after the introduction of kernel 2.6 and HAL, where mount points could be created on-the-fly.

Now I see that when using Xfce, everything gets mounted under /run. I just googled for /run and found this, erm, explanation:

https://lists.fedoraproject.org/pipe...ch/150031.html

And now I wonder.
  1. How can I explain the utility of /run to my Linux students, when I'm not quite sure what it's good for myself?
  2. It looks like /media is orphaned. Correct me if I'm wrong.
  3. Can we expect other improvements on mountpoints like /var/crap/lennart in the future?

Any suggestions?

acid_kewpie 11-28-2012 04:49 AM

well that link seems to explain what it's for extremely well, but as you're discussing it alongside /media I think you just need to read it again more closely. udev and other core services need a place to write data to, that is available extremely early in the boot process and persists into the long term booted state of the system. That's pretty much it. ?media is where dvd's get mounted, that's not related to this at all. Other changes? Sure, the system is evolving, and will never stop doing so.

NonNonBa 11-28-2012 04:59 AM

Hello,

According to the (future) FHS v3, it is a replacement for /var/run (FHS v2.3). /media seems still in use, so it is not intended to be a replacement for it.

markush 11-28-2012 05:25 AM

kikinovak, take it as an example for the ongoing development in the Linux/Opensource world. Tell your students that it's not yet clear which way the concept of udev will go in the future. Tell them that there isn't a company which defines the standards (like in the Windowsworld) (ok, we have Redhat instead ;)) but that there are different opinions about which direction to go.

Maybe they will at least understand how opensource and free software function.

Markus

GazL 11-28-2012 05:30 AM

/run makes some sense:

I'd rather see a /run than have udev, md etc. spray hidden directories all over /dev where they don't belong. Of course, I'd much prefer to have a sensible early boot that didn't require using this sort of nonsense in the first place, but sadly those days are gone.

As for putting mountpoints under "/run/media/$USER/", I can see how they might be ok when only ever using a point/click interface, but as soon as you end up having to type directory paths in, either in the command line, or in some sort of gui text entry dialog, they just make things ugly and inconvenient and I much prefer the old way of doing it.

kikinovak 11-28-2012 06:00 AM

Quote:

Originally Posted by acid_kewpie (Post 4838628)
well that link seems to explain what it's for extremely well, but as you're discussing it alongside /media I think you just need to read it again more closely. udev and other core services need a place to write data to, that is available extremely early in the boot process and persists into the long term booted state of the system. That's pretty much it. /media is where dvd's get mounted, that's not related to this at all. Other changes? Sure, the system is evolving, and will never stop doing so.

Xfce 4.6 under Slackware 13.37 mounted everything (DVD, USB stick, external disk, camera) under /media.

Xfce 4.10 under Slackware 4.10 mounts everything (DVD, USB stick, external disk, camera) under /run/media/something.

Hence my question.

acid_kewpie 11-28-2012 06:08 AM

Quote:

Originally Posted by kikinovak (Post 4838683)
Xfce 4.6 under Slackware 13.37 mounted everything (DVD, USB stick, external disk, camera) under /media.

Xfce 4.10 under Slackware 4.10 mounts everything (DVD, USB stick, external disk, camera) under /run/media/something.

Hence my question.

Ahh, fair do's (despite this slackware time travel there!) my mistake.

gnashley 11-28-2012 11:49 AM

"/var/crap/lennart" -I love it!

ponce 11-28-2012 12:13 PM

http://www.linuxquestions.org/questi...7/#post4803572

sahko 11-28-2012 02:03 PM

Quote:

Originally Posted by GazL (Post 4838660)
/run makes some sense:

I'd rather see a /run than have udev, md etc. spray hidden directories all over /dev where they don't belong. Of course, I'd much prefer to have a sensible early boot that didn't require using this sort of nonsense in the first place, but sadly those days are gone.

As for putting mountpoints under "/run/media/$USER/", I can see how they might be ok when only ever using a point/click interface, but as soon as you end up having to type directory paths in, either in the command line, or in some sort of gui text entry dialog, they just make things ugly and inconvenient and I much prefer the old way of doing it.

+1

The lwn discussion on the matter is also nice http://lwn.net/Articles/436012/

sahko 11-28-2012 02:11 PM

Quote:

Originally Posted by kikinovak (Post 4838683)
Xfce 4.6 under Slackware 13.37 mounted everything (DVD, USB stick, external disk, camera) under /media.

Xfce 4.10 under Slackware 4.10 mounts everything (DVD, USB stick, external disk, camera) under /run/media/something.

Hence my question.

Thats udisks2 at work. KDE 4.8 which still uses udisks mounts under /media.
PS. Thats gonna change in KDE 4.10.

jtsn 11-29-2012 07:09 AM

Quote:

Originally Posted by kikinovak (Post 4838621)
How can I explain the utility of /run to my Linux students, when I'm not quite sure what it's good for myself?

Use BSD for teaching and explaining well-thought OS design. The chaos you find in /etc, /lib (and now /run) of a typical Linux distribution is not that different from the \WINDOWS directory of an other well-known PC operating system.

It's just mindless namespace pollution, no big picture behind it.

jpollard 12-02-2012 09:23 AM

/run is mounted as a tmpfs filesystem. It is intended to hold data that is not relevant after a reboot. The use of tmpfs allows it to be recreated on every boot.

That said, the use of /run is to hold files containing things like service daemon pid values. These have no use after a reboot. The advantage is that they are automatically disposed of, and easily recreated.

The problem comes up in that some projects overuse it. GDM (and formerly KDM) would put user Xauthority files in there. That requires that the /run directory be user readable, and specific directories (and files) be accessible, and writable.

This introduces a security problem in that it gives the user the ability to use up the storage space (and inodes) associated with the filesystem used for /run. This becomes a denial-of-service weakness as it allows any user with such access to fill the /run filesystem (either storage, inodes or both), and prevent other users (and daemon restarts) from succeeding.

I first saw this in Fedora, and is only now being cleaned up (KDM and Gnome now use /tmp). The only Xauthority files there now are for the hand off of initial X authority keys between GDM/KDM, the X server, and the login greeter process, so this isn't a problem.

kingbeowulf 12-04-2012 01:46 AM

shifting automountng from /media/* to /run/[user]/* was just plain idiocy. According to the links provided earlier in this thread (fedora and FHS), removable media goes into /media and /run is for run time variable data. Placing mount points into /run violates its defined purpose.

Just my 2 cents.

But what do I know? Its not like I ever rolled my own distro.

jpollard 12-04-2012 09:27 AM

That is another of those "overuse" things. I believe fedora is now moving to /media being a tmpfs mount as well. At least, that is what it is on my F16, and F17 (in a VM).

There are a number of such mounts:
Code:

tmpfs            510044      80    509964  1% /dev/shm
tmpfs            510044    6868    503176  2% /run
tmpfs            510044      0    510044  0% /sys/fs/cgroup
tmpfs            510044      0    510044  0% /media

In none of these cases does it matter what the contents are after a reboot - they are all reinitialized with dynamic data.

gnashley 12-05-2012 03:09 AM

I don't see the point in having a tmpfs which is only used for mounting removable devices. Am I missing something?

acid_kewpie 12-05-2012 04:11 AM

Quote:

Originally Posted by gnashley (Post 4843053)
I don't see the point in having a tmpfs which is only used for mounting removable devices. Am I missing something?

yeah, I wondered that too. I guess it at least ensures nothing else is put there permanently? Also the directories are possibly managed more easily that way too, as they would be created on demand and not need to persist?

jpollard 12-05-2012 09:46 AM

The mountpoints are created within the tmpfs /media. So access to it is /media/<name>.

The mountpoint name is either based on the volume name, or possibly from a UUID name.

Unless you clean up the directory on removal (it does), you end up forcing a lot of disk churn just creating/deleting mountpoints. Making it tmpfs avoids that churn, and this in turn helps situations with systems based on flash memory as no actual writes to a disk occur.

acid_kewpie 12-05-2012 12:38 PM

Quote:

Originally Posted by jpollard (Post 4843264)
The mountpoints are created within the tmpfs /media. So access to it is /media/<name>.

The mountpoint name is either based on the volume name, or possibly from a UUID name.

Unless you clean up the directory on removal (it does), you end up forcing a lot of disk churn just creating/deleting mountpoints. Making it tmpfs avoids that churn, and this in turn helps situations with systems based on flash memory as no actual writes to a disk occur.

significant IO load from creating one directory?? Pfft, no way!

jpollard 12-05-2012 01:06 PM

Yes. Very significant to SSD.

creating/deleting a directory requires at a minimum of one block replacement. On an SSD, that may actually require rewriting several blocks - the pointer to the current block (the new block is not the same as the original like it is on a physical disk), the block iteslf (block replaced... unless a directory split occurs - then it becomes 4). And that would be on each insert/removal of a device. And then there are the inode blocks, and the allocation maps... Not to mention the timestamps...

Now you CAN eliminate the multiple updates due to timestamps (just have the filesystem mounted noatime), but you can't eliminate the updates due to creation.

And it is even more significant to speed. tmpfs is many times faster.

All it really does is minimize wear and tear on ssd/memory sticks with a limited lifetime use.

I'm just wondering how long it will be before /var/lock is moved to another filesystem mounted tmpfs (I would guess at something like /run/lock...)

Now, do I think everything tmpfs is used for appropriate? Nope. Is speed all that important? Not to workstations.

Not good on servers at all - the memory itself is more useful elsewhere, and in addition, there are very few USB devices plugged into/removed from servers anyway.

GazL 12-05-2012 02:48 PM

There already is a "/run/lock", but replacing /var/lock with it is a mistake. Not all locks should be cleared on a system reboot. Sometimes you need them to persist. Moving those locks that can and should be cleared on a reboot to /run/lock does make sense however.

sahko 12-05-2012 07:47 PM

I think /media is going away completely. Arch Linux has already done so.
It is only part of the 'old' udisks1 package which uses it.
http://thread.gmane.org/gmane.linux.arch.devel/18670

jpollard 12-06-2012 06:14 AM

The problem with putting it in /run/media where /run is a tmpfs, is again, security. It allows users to put anything into a directory (at a minimum by volumne/UUID naming of the plug in). And thus causing other system issues.

It might be very difficult to exploit though... and rather unlikely.


All times are GMT -5. The time now is 05:22 AM.