Introducing /run
| From: | Lennart Poettering <mzerqung-AT-0pointer.de> | |
| To: | Fedora Development ML <devel-AT-lists.fedoraproject.org> | |
| Subject: | What's this /run directory doing on my system and where does it come from? | |
| Date: | Wed, 30 Mar 2011 13:54:30 +0200 | |
| Message-ID: | <20110330115430.GA3115@tango.0pointer.de> | |
| Archive‑link: | Article |
Heya, I just uploaded a new version of systemd into F15, which establishes a directory /run in the root directory. Most likely you'll sooner or later stumble over it, so here's an explanation what this is and why this is. It's a fairly minor technical change, though presumably people consider this a bigger political change, so I guess this deserves an explanation: For quite a while programs involved with early boot used to place runtime data in /dev under numerous hidden dot directories. /dev/.udev was the first one, but over time this grew to at least /dev/.mdadm, /dev/.systemd, /dev/.mount, dracut, initscripts and more tools. (Other distros have even more) The reason they used directories there is that /dev was known to be a tmpfs and available from the first instant the machine was booted. /var/run otoh is only available very late at boot, since /var might reside on a separate file system. However, /dev always has been an inappropriate and ugly place for runtime data: runtime data is not a device node, and thus simply does not belong there. Also, hiding the existance of directories from the administator is a bad idea. Then, the fact that some runtime data was placed in /var/run/xxx, and other in /dev/.yyy is often not understandable to ther user, and especially when tools originally intended to be used only after boot are needed during early boot a complicated move between these directories needed to take place. Over time different distributions experimented with different broken solutions for the early-runtime-dir problem: on Debian /lib/init/rw was introduced, a tmpfs fs mounted during early boot. On Ubuntu /var/run was mounted as tmpfs even before /var itself was mounted, with some really ugly bind mount magic. Most software however just sidestepped the issue and used /dev/.xxx. In the past weeks key people from the Debian, Suse, Ubuntu and Fedora camps (and others, too) discussed the whole issue forth and back, to find a solution to stop the misuse of /dev before it becomes even more widespread. Various solutions have been suggested, but in the end it all boiled down to the fact that /var/run does not belong beneath /var and what we really want is a top-level directory /run, and that that is the only really clean solution. The only reason why nobody dared to actually implement such a directory was unwillingness to deal with the political backlash, especially messy discussions on mailing lists like this one. Understanding this, we came to the conclusion that we should rather implement what everybody thinks is the right technical solution, instead of evading the political backlash for it. And so we implemented this. With this upload Fedora and Suse have already adopted /run now. Debian folks will suggest this for their coming release. Ubuntu has agreed with introducing /run as well. Dracut, udev and systemd have already been updated upstream to make use of /run. We expect mdadm and mount to follow suit quickly. A few years back Debian folks already suggested introduction of /run, and even pinged LSB folks about this, and back then there even was a vaguely positive response from them. So, what is implemented in F15 precisely? /run is now a tmpfs, and /var/run is bind mounted to it. /var/lock is bind mounted to /run/lock. Applications can use /run the same way as /var/run. Since the latter is FHS/LSB most apps should just use the latter, only early boot stuff should use /run, for now. The folks who have packages where this applies already have been informed. If you haven't heard from any of us, then this doesn't apply to you. So, what's the benefit of this again? - There's only one tmpfs used, backing /run, /var/lock and /var/run, reducing a bit the ever increasing amount of tmpfs' used on a default system. - All runtime data at the same place. systemd's, udev's, dracut's data are all beneath /run and /var/run now. Easily discoverable to the admin. For the first time you can see the data all these important tools used on your system store just like any other by doing "ls /var/run". - Nothing is hidden anymore. The admin can see everything beneath /var/run and /run, no hidden dot-files anymore. - We have standardized the early-runtime-dir solution across all major distributions - The people involved feel much better since they don't have to misuse /dev anymore - The lifecycle properties of directories are clear from the top-level directory name. Lifecycle properties do no longer change the further you go down your tree. i.e. /var is "persistant runtime data" and /run is "volatile runtime data", and /etc is "persistant system config data", and so on. The ugliness that /var/run abd /var/lock had completely different liftime guarantees than /var where they both reside in is gone. So, this is what is implemented for F15 now. For F16 we will make a minor change on top of this: /var/run and /var/lock will become symlinks to /run (resp /run/lock), so that we don't have to use bind mounts anymore which are not the most beautiful thing to use by default, and confusing to the admin. Due to the implications of symlinks and RPM we didn't want to make that change in F15. The actual code changes we needed to implement this scheme were trivial (basically, just bind mount /var/run and /var/lock instead of mounting two new tmpfs' to them.), which is why we opted to do this so late in the F15 cycle. However, the political implications are much bigger I guess, so let's see what a fantastic flamewar we can start with this on fedora-devel now. Flame away! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
(Log in to post comments)
Introducing /run
Posted Mar 30, 2011 14:23 UTC (Wed) by rriggs (guest, #11598) [Link]
Introducing /run
Posted Mar 30, 2011 14:39 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
FHS hasn't been updated in a long time. However a request has been opened at
http://bugs.freestandards.org/show_bug.cgi?id=718
I completely expect nothing to be done about it.
Fixed link
Posted Oct 19, 2014 1:22 UTC (Sun) by JesseW (subscriber, #41816) [Link]
Fixed link
Posted Oct 19, 2014 2:01 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
Introducing /run
Posted Mar 30, 2011 15:05 UTC (Wed) by rleigh (guest, #14622) [Link]
Reading the thread, there seemed to be good consensus on the need for /run, with one vocal individual disagreeing; however, the disagreement did not appear to address the fact that the existing FHS does not address the need for /run, and that standards are built on consensus, not set in stone. I'm sure that /run could be added to the FHS following its introduction. The FHS has not always established existing practice though--I'm still waiting for /libexec which both the BSDs and GNU coding standards have long supported, and it's a rather glaring incompatibility.
One thing I was going to mention was that LVM will no longer need to keep its cache files under /etc, which was a long-standing flaw in it, making a read-only rootfs easier to achieve. I subsequently found Alasdair Kergon's comments in the thread, which were nice to see. We could also get rid of /etc/mtab as well, without the need for a symlink to /proc/mounts before mount(8) is fully capable of operating without a writable mtab.
Is anyone working on supporting /run in Debian, and replacing /lib/init/rw?
Regards,
Roger
Introducing /run
Posted Mar 30, 2011 15:25 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
Lennart
Introducing /run
Posted Mar 30, 2011 15:37 UTC (Wed) by rvfh (guest, #31018) [Link]
I believe it's one of your goals too, isn't it?
Good job.
Introducing /run
Posted Mar 30, 2011 16:17 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
Lennart
Introducing /run
Posted Mar 30, 2011 16:26 UTC (Wed) by rleigh (guest, #14622) [Link]
http://article.gmane.org/gmane.linux.utilities.util-linux...
http://thread.gmane.org/gmane.linux.utilities.util-linux-...
Until Debian adopts systemd exclusively, we are still going to need the above issues fixing before making mtab a symlink. While I would like to see systemd adopted in Debian, I think support for non-Linux kernels is a potential blocker here, mainly for kfreebsd, and Hurd to a lesser extent, if we are to have a unified init across all supported kernels. Not that any of that is my call, just a consideration to bear in mind. It is also likely that Debian will allow other inits such as upstart, which will also require util-linux-ng and related tools to support the above as well.
Regards,
Roger
Introducing /run
Posted Mar 30, 2011 18:49 UTC (Wed) by cmorgan (guest, #71980) [Link]
Introducing /run
Posted Mar 31, 2011 14:21 UTC (Thu) by nye (guest, #51576) [Link]
Note that the GP did not say 'platforms', but 'kernels', which is an important distinction in this context.
Introducing /run
Posted Mar 31, 2011 4:49 UTC (Thu) by ebiederm (subscriber, #35028) [Link]
Introducing /run
Posted Mar 31, 2011 9:38 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Introducing /run
Posted Mar 30, 2011 14:36 UTC (Wed) by nhippi (guest, #34640) [Link]
Introducing /run
Posted Mar 30, 2011 17:18 UTC (Wed) by nix (subscriber, #2304) [Link]
(new directories in / do not bite, as long as they don't propagate too much. But /run is plainly good.)
Introducing /run
Posted Mar 30, 2011 23:24 UTC (Wed) by roblucid (guest, #48964) [Link]
I say this, and I HATED the dictat that / & /usr ought not be in seperate FS's no more, where I was in the old-fart reactionary camp, believing in the right to segregate different kinds of data, to ease the admin of systems.
Fact was, I would create my own TLD's for each significant group of users, and not rely on /usr or /home, for a local machine centric view of the world.
Introducing /run
Posted Mar 31, 2011 8:19 UTC (Thu) by rleigh (guest, #14622) [Link]
Introducing /run
Posted Mar 31, 2011 16:46 UTC (Thu) by vonbrand (guest, #4458) [Link]
Great! Every file handled by the package manager goes under /pkg, everything else under /nopkg. Nice, orderly system with /pgg/emacs, /pkg/gcc, ... ;-)
Introducing /run
Posted May 4, 2011 21:29 UTC (Wed) by nix (subscriber, #2304) [Link]
nix@mutilate 125 /home/nix% ls -l /pkg/emacs/
total 12
drwxr-xr-x 6 root root 4096 Apr 6 16:49 23.3-5568-1
drwxr-xr-x 6 root root 4096 May 2 22:55 24.1-104079
drwxr-xr-x 6 root root 4096 May 4 14:46 24.1-104105
nix@mutilate 126 /home/nix% ls -l /pkg/ncurses/
total 20
drwxr-xr-x 5 root root 4096 Sep 11 2009 5.7-20090815-old
drwxr-xr-x 6 root root 4096 Jan 16 14:30 5.7-20110108
drwxr-xr-x 6 root root 4096 Jan 16 14:35 5.7-20110108-32
drwxr-xr-x 6 root root 4096 Jan 16 14:31 5.7-20110108-wide
drwxr-xr-x 6 root root 4096 Jan 16 14:39 5.7-20110108-wide-32
All installed via DESTDIR and symlinked into place by graft.
Introducing /run
Posted Mar 30, 2011 14:46 UTC (Wed) by nvloff (guest, #73737) [Link]
On a more serious note: it seems like this whole standards thing seems dead ( FHS, freestandards.org, etc). And like Python is defined by it's implementation, the current state of the Debian/Ubuntu/Fedora distributions should be considered the standard instead of some document that was last updated 6 years ago.
Introducing /run
Posted Mar 30, 2011 19:26 UTC (Wed) by mmcgrath (guest, #44906) [Link]
It's a fallacy to think that just because something is old that it is invalid or somehow faulty.
Introducing /run
Posted Mar 30, 2011 19:40 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Introducing /run
Posted Mar 31, 2011 13:55 UTC (Thu) by jcm (subscriber, #18262) [Link]
Introducing /run
Posted Mar 31, 2011 20:26 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Introducing /run
Posted Mar 30, 2011 14:59 UTC (Wed) by sahko (guest, #54088) [Link]
Introducing /run
Posted Mar 31, 2011 19:39 UTC (Thu) by vonbrand (guest, #4458) [Link]
SELinux is certainly not an "application"...
Introducing /run
Posted Mar 30, 2011 15:01 UTC (Wed) by handock (guest, #73633) [Link]
He just transformed easy hackable start-up shell scripts
into buggy and unmaintainable C code. (systemd)
But that was only his first step. He's now obviously aiming
to infect the remaining sane rests of the Linux-world with his
idiotic ideas and world-view.
And the developers applaud and follow him like mindless sheep.
Introducing /run
Posted Mar 30, 2011 15:04 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
Introducing /run
Posted Mar 30, 2011 15:07 UTC (Wed) by handock (guest, #73633) [Link]
Introducing /run
Posted Mar 30, 2011 15:11 UTC (Wed) by Trelane (subscriber, #56877) [Link]
Introducing /run
Posted Mar 30, 2011 17:12 UTC (Wed) by Trelane (subscriber, #56877) [Link]
> Finally, someone says it!
handock:
> Yes, it had to be.
Trelane:
> ;) Great trolling, no?
petegn:
> Deutsch, bitte
[toggle and recurse]
Introducing /run
Posted Mar 30, 2011 17:16 UTC (Wed) by Trelane (subscriber, #56877) [Link]
Introducing /run
Posted Mar 30, 2011 17:19 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
Introducing /run
Posted Mar 30, 2011 17:20 UTC (Wed) by Trelane (subscriber, #56877) [Link]
Introducing /run
Posted Mar 30, 2011 17:30 UTC (Wed) by jengelh (subscriber, #33263) [Link]
Introducing /run
Posted Mar 30, 2011 17:53 UTC (Wed) by Trelane (subscriber, #56877) [Link]
Introducing /run
Posted Mar 30, 2011 18:13 UTC (Wed) by jengelh (subscriber, #33263) [Link]
Not a front-rounded vowel AFAICT.
Introducing /run
Posted Mar 30, 2011 18:42 UTC (Wed) by mpr22 (subscriber, #60784) [Link]
o-doubleacute is definitely a front mid rounded vowel. Specifically, a long front mid rounded vowel, as Hungarian has fully phonemic vowel length.
Introducing /run
Posted Mar 30, 2011 18:57 UTC (Wed) by jengelh (subscriber, #33263) [Link]
Introducing /run
Posted Mar 30, 2011 19:11 UTC (Wed) by Trelane (subscriber, #56877) [Link]
Introducing /run
Posted Mar 30, 2011 18:07 UTC (Wed) by Slumberthud (subscriber, #45657) [Link]
Introducing /run
Posted Mar 30, 2011 18:21 UTC (Wed) by mezcalero (subscriber, #45103) [Link]
Introducing /run
Posted Mar 30, 2011 18:30 UTC (Wed) by dark (guest, #8483) [Link]
oePttering? Now I'm confused :(
Introducing /run
Posted Mar 30, 2011 23:32 UTC (Wed) by baldridgeec (guest, #55283) [Link]
"Puh(r)-turing" -- with the "(r)" being a soft slur into the next syllable.
Leonard, is that about right? Or do I need to try to start bringing Goethe into conversation more often so I can correct peoples' pronunciation? :)
Introducing /run
Posted Mar 31, 2011 2:15 UTC (Thu) by mezcalero (subscriber, #45103) [Link]
Introducing /run
Posted Mar 31, 2011 2:21 UTC (Thu) by baldridgeec (guest, #55283) [Link]
Do the exclamation points as pronunciation guides mean the same thing they do in Ndebele?
(sorry, couldn't resist -- but seriously... I now have no idea how to pronounce Goethe. To Wikipedia!)
Introducing /run
Posted Oct 20, 2017 9:42 UTC (Fri) by poruid (guest, #15924) [Link]
Introducing /run
Posted Mar 30, 2011 20:54 UTC (Wed) by nix (subscriber, #2304) [Link]
That way, Lennart could describe the pronunciation of his name using freaky-looking symbols that nobody knows how to pronounce, increasing global confusion still further. Surely a worthy goal.
Introducing /run
Posted Mar 31, 2011 0:29 UTC (Thu) by ewan (subscriber, #5533) [Link]
Introducing /run
Posted Mar 31, 2011 0:58 UTC (Thu) by dmarti (subscriber, #11625) [Link]
Or it could be a libcanberra sample application.
Introducing /run
Posted Oct 20, 2017 15:56 UTC (Fri) by karkhaz (subscriber, #99844) [Link]
Introducing /run
Posted Mar 30, 2011 15:50 UTC (Wed) by ovitters (guest, #27950) [Link]
Introducing /run
Posted Mar 30, 2011 17:21 UTC (Wed) by rwmj (subscriber, #5474) [Link]
It's true that systemd replaces shell init scripts with C, and it's at least arguable that the C code will be more buggy than the shell scripts.
The question though is whether it matters that the shell scripts are replaced with C.
After all, you weren't really supposed to edit those init scripts, and they were written in a highly formulaic variety of shell with lots of canned functions. It was very easy to make mistakes in those shell scripts, and keeping them all up to date with the latest LSB/init standards was a constant battle.
Instead of editing those shell scripts, you should use /etc/sysconfig to make changes to how daemons start up.
Furthermore, systemd AIUI can use init scripts if you want to.
Introducing /run
Posted Mar 30, 2011 17:26 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Certainly silly to get all railed up and call Lennart a troll for being a messenger in a widely agreed upon and sensible change. The other criticism happens to be invalid as well as you have pointed out.
Introducing /run
Posted Mar 30, 2011 17:53 UTC (Wed) by dcg (subscriber, #9198) [Link]
Introducing /run
Posted Mar 31, 2011 2:12 UTC (Thu) by k8to (guest, #15413) [Link]
- it is not a widely agreed upon change
- it makes the system markedly worse according to the inspectability axis
Introducing /run
Posted Mar 31, 2011 16:54 UTC (Thu) by vonbrand (guest, #4458) [Link]
Please...
- Major distributions have adopted/are considering it (Fedora, Debian, OpenSUSE at least)
- "Inspectable" for whom? The maze of shell scripts legated by
sysvinitisn't exactly transparent... Sure,systemddoes get some using to, but from my (rabid Fedora fan, rawhide follower; and thus user for some time now) perspective it's much better than what came before; plus is promises to really handle dependencies, not just "(try to) start this after that one on boot, and hope for the best" ordering.
Introducing /run
Posted Apr 1, 2011 3:57 UTC (Fri) by motk (subscriber, #51120) [Link]
Introducing /run
Posted Mar 30, 2011 18:47 UTC (Wed) by aliguori (subscriber, #30636) [Link]
It's true that systemd replaces shell init scripts with C, and it's at least arguable that the C code will be more buggy than the shell scripts.I think that's a simplification of what systemd does and puts too much importance on language which I think is really just an implementation detail here. My understanding of systemd is that it eliminates the explicit dependency expressed in most init systems with an implicit one largely by using file descriptor inheritance.
Since most tools really don't depend on an application to be running, but just depend on being able to open a socket, you can tremendously simplify the problem by making all of the sockets available at once and starting pretty much everything in parallel.
Since startup dependencies are now simplified so greatly, the per task startup is simplified so much that for the most part, it's trivial to do it all with just plain C.
So a better way to think of it is that systemd doesn't replace init scripts with C, it fundamentally eliminates the need to have init scripts by tremendously simplifying the problem of starting up tasks with complex dependency hierarchies.
Introducing /run
Posted Mar 30, 2011 20:31 UTC (Wed) by vonbrand (guest, #4458) [Link]
I think that's a simplification of what systemd does and puts too much importance on language which I think is really just an implementation detail here. My understanding of systemd is that it eliminates the explicit dependency expressed in most init systems with an implicit one largely by using file descriptor inheritance.
Make that no dependencies and we'll agree (The standard init stuff just says in which order stuff should (!) be (tried to) run when the system starts in a given runlevel, nothing more. Fragile as hell, but even so vastly better than what came before...).
Introducing /run
Posted Mar 30, 2011 23:42 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]
I'm not sure that's a fair description of what systemd does. The biggest thing it does is to refactor the init system. It takes the boilerplate part of all the init scripts and combines it into a single implementation in C, and turns the small variable part into config files. Eliminating the copy and paste proliferation of independent init files should tend to reduce bugs, not increase them.
Introducing /run
Posted Mar 30, 2011 16:55 UTC (Wed) by drag (guest, #31333) [Link]
I hope so. Linux is better because of it.
Introducing /run
Posted Mar 31, 2011 2:06 UTC (Thu) by JEDIDIAH (guest, #14504) [Link]
>
> I hope so. Linux is better because of it.
No. This is just change for it's own sake like a lot of the stuff that's been going on lately (Wayland, Unity). This seems to be about people's aesthetic preferences and really has little functional value.
Introducing /run
Posted Mar 31, 2011 2:18 UTC (Thu) by Trelane (subscriber, #56877) [Link]
I'd love to be able to run with / being on read-only media in some scenarios. (I'm a paranoid guy. :)
Introducing /run
Posted Mar 31, 2011 4:44 UTC (Thu) by AndreE (guest, #60148) [Link]
Why don't you start jumping up and down about all the stuff that broke the unix best practices that necessitated /run ?
Introducing /run
Posted Mar 31, 2011 5:06 UTC (Thu) by drag (guest, #31333) [Link]
Well change is good. It is just people doing their best to make something they like better.
And aesthetics do matter. Isn't that part of the hacker ethos? There is certain aesthetic quality to the design of Unix, right?
The world moves on, things change, people adapt.
Like this /run thing...
Were not people flipping apeshit just a while ago about how SystemD flashed a warning that having a separate /usr is a unsupported configuration?
And how, in reality, that was not a supported configuration for years and years. It can work, but it's not guaranteed to work. You can make it work even if it didn't... but it would require inelegant solutions.
But now when the same guy says that we should have a /run directory so that programs always have a place to store their runtime temporary files... so people can have /var mounted on a different partition without a bunch of ugly hacks going on in /dev/.??* files... now all of a sudden that is a horrible suggestion.
What is the alternative? Just keep shoving more and more information into /dev/.??* because that is the only file system that developers know will be there at immediate boot-up?
Maybe if we modify things a bit and try to improve the system then we can finally have a system that really does support things like read-only root and remote-mount /usr/* directories.
Oh. And Unity is not-so-hot. Ubuntu is pushing too hard on it and it needs to wait till next release. I tried using it for a few weeks, but it's just not a very pleasant experience.
So I ditched Ubuntu and went with Fedora 15 Alpha. I tried to go back to Debian first, but I couldn't get it to work the way I wanted. Gnome 3 is just not well enough put together for Debian yet.
Fedora is FANTASTIC. Gnome 3 has been stable for me. Open source Gallium Radeon drivers are fast and can actually play most games now. The bug track stuff that Fedora has built in to help file bug reports on application crashes is super-duper cool. Hopefully it won't take much longer to get codec acceleration (maybe 8-10 months if things go well) and then I would be very happy.
I wouldn't be so negative about change if I was you. It has it's ups and downs. Ideally it will have more ups.
Introducing /run
Posted Apr 1, 2011 3:59 UTC (Fri) by motk (subscriber, #51120) [Link]
Introducing /run
Posted Mar 30, 2011 17:13 UTC (Wed) by vrfy (guest, #13362) [Link]
It's actually a whole group a sheep that just constantly moves on. It's the group who does the work, and who needs solutions to make the real things happen.
The mindless complainers on the other hand, their impact is close to zero in the end.
Introducing /run
Posted Mar 30, 2011 17:34 UTC (Wed) by wahern (subscriber, #37304) [Link]
I'm not the biggest fan of systemd because it's yet another incompatible daemon manager (compare OS X launchd, Solaris SMF, daemontools... and OpenBSD is just *now* moving to rc.d scripts for ports!) But in most ways it's an improvement over the _existing_ init.d systems. init.d itself isn't broken, IMO, but Redhat especially--other distros, too--made it broken by trying to use it to paper over all the deficiencies in other people's broken code, rather than *fixing* the broken code.
Introducing /run
Posted Mar 30, 2011 17:36 UTC (Wed) by dcg (subscriber, #9198) [Link]
2) You can use shell scripts with systemd. It's even more configurable than the old init scripts.
Introducing /run
Posted Mar 30, 2011 18:03 UTC (Wed) by jmorris42 (guest, #2203) [Link]
/run leads to a simpler and more understandable system and that is the UNIX Way.
Introducing /run
Posted Mar 30, 2011 20:07 UTC (Wed) by aleXXX (subscriber, #2742) [Link]
Sounds like a good and clean thing.
Alex
Introducing /run
Posted Mar 30, 2011 20:56 UTC (Wed) by nix (subscriber, #2304) [Link]
Introducing /run
Posted Jun 19, 2011 22:46 UTC (Sun) by Yaro (guest, #75783) [Link]
Ever notice how, whenever someone calls for him to fix PA's problems, he blames it on either ALSA, drivers, or distributions? It's that sort of passing the blame on problems with their software that makes the maintainer of glibc so unpopular.
Introducing /run
Posted Mar 30, 2011 20:22 UTC (Wed) by job (guest, #670) [Link]
Introducing /run
Posted Mar 30, 2011 23:51 UTC (Wed) by baldridgeec (guest, #55283) [Link]
I never had a broken sound card that wouldn't multiplex with ALSA, but I do believe it happened, and then I saw EarCandy - that was really the "critical app" that demonstrated the usefulness of Pulse to me. And the recent versions get out of the way of jackd automatically... good stuff.
Introducing /run
Posted Mar 31, 2011 4:40 UTC (Thu) by AndreE (guest, #60148) [Link]
"Flame away!"
Posted Mar 30, 2011 17:30 UTC (Wed) by cesarb (subscriber, #6266) [Link]
It is great that we have people willing to do what is needed to enhance the Linux infrastructure, without being afraid of the predictable and unavoidable controversy.
And I am thankful to Corbet for posting this email here. Without seeing it, I would still be thinking "what an ugly change!".
"Flame away!"
Posted Mar 30, 2011 17:36 UTC (Wed) by vrfy (guest, #13362) [Link]
If you want, you can do this manually already today. Systemd copes just fine with that, and it gets rid of the two bind mounts. See the details here:
http://cgit.freedesktop.org/systemd/commit/?id=2b583ce657...
"Flame away!"
Posted Mar 30, 2011 17:48 UTC (Wed) by cesarb (subscriber, #6266) [Link]
It is another thing it being done by default, with thousands of people "testing" it (most people will see no need to change from the default), and with every thirdy-party program having to deal with it, with even obscure breakage caused by it being found sooner or later.
Do not underestimate the power of defaults.
"Flame away!"
Posted Mar 30, 2011 18:39 UTC (Wed) by vrfy (guest, #13362) [Link]
It's just not entirely trivial to change that on the running system during a package update, but we will get there.
"Flame away!"
Posted Apr 1, 2011 3:45 UTC (Fri) by elanthis (guest, #6227) [Link]
There's a _reason_ Windows requires a reboot for many updates.
(Windows fails in that it used to just require a reboot for everything out of laziness, which made it incredibly annoying to update all those things for which a reboot was totally unnecessary. It's a lot better about that these days. Many application vendors still demand reboots after their app installs, but those are generally ignorable and are not Windows' fault.)
"Flame away!"
Posted Apr 2, 2011 12:28 UTC (Sat) by kleptog (subscriber, #1183) [Link]
Introducing /run
Posted Mar 30, 2011 17:45 UTC (Wed) by martinfick (subscriber, #4455) [Link]
Introducing /run
Posted Mar 30, 2011 18:19 UTC (Wed) by rleigh (guest, #14622) [Link]
Keeping them separate also means users can't DoS the system by using all the space/inodes and thus prevent the creation of new pidfiles/lockfiles etc.
Regards,
Roger
/tmp and /var/tmp
Posted Mar 30, 2011 19:01 UTC (Wed) by dmarti (subscriber, #11625) [Link]
The other problem is /var/tmp, which is now just an extra /tmp that doesn't deserve its own tmpfs, but that some software wants to use. SELinux complains about if you make it a symlink to ../tmp. Bind mount it to /tmp in /etc/fstab?tmpfs /tmp tmpfs defaults 0 0 /tmp /var/tmp tmpfs bind 0 0tmpfs as many places as possible FTW.
/tmp and /var/tmp
Posted Mar 30, 2011 19:49 UTC (Wed) by makomk (guest, #51493) [Link]
/tmp and /var/tmp
Posted Mar 30, 2011 19:56 UTC (Wed) by dmarti (subscriber, #11625) [Link]
Any examples of programs that put something important in there?
/tmp and /var/tmp
Posted Mar 30, 2011 20:59 UTC (Wed) by nix (subscriber, #2304) [Link]
(TBH I much prefer this over the vim habit of scattering .swp files everywhere. Emacs has a similar feature: you can drop all autosave files into a single directory without much effort.)
/tmp and /var/tmp
Posted Mar 30, 2011 21:18 UTC (Wed) by cortana (subscriber, #24596) [Link]
/tmp and /var/tmp
Posted Apr 1, 2011 17:28 UTC (Fri) by nix (subscriber, #2304) [Link]
/tmp and /var/tmp
Posted Apr 1, 2011 19:13 UTC (Fri) by dtlin (subscriber, #36537) [Link]
:h dir - For Unix and Win32, if a directory ends in two path separators "//" or "\\", the swap file name will be built from the complete path to the file with all path separators substituted to percent '%' signs. This will ensure file name uniqueness in the preserve directory.(Same with 'bdir'.)
/tmp and /var/tmp
Posted Mar 31, 2011 12:38 UTC (Thu) by NAR (subscriber, #1313) [Link]
/tmp and /var/tmp
Posted Mar 30, 2011 21:06 UTC (Wed) by fritsd (guest, #43411) [Link]
/tmp and /var/tmp
Posted Mar 30, 2011 21:12 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
That said, I don't specifically know whether any common programs store data in /var/tmp which must persist across a reboot. I do know that MySQL occasionally stores certain temporary files there; these may be need for recovery after a crash or power interruption. KDE also stores cache files under /var/tmp; losing these at every reboot would be likely to negatively impact performance.
/tmp and /var/tmp
Posted Mar 30, 2011 19:59 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
/tmp and /var/tmp
Posted Mar 30, 2011 20:27 UTC (Wed) by Darkmere (subscriber, #53695) [Link]
/tmp and /var/tmp
Posted Mar 30, 2011 23:36 UTC (Wed) by roblucid (guest, #48964) [Link]
/tmp is meant to be small, fast and ephemeral, with a purge across a reboot being acceptable or clean out if the file's not accessed for a day or so.
Of course if you *must* have a /tmp/humungeous then nothing to stop a mount under /tmp, or a symlink to fallow area, for you to fill.
/tmp and /var/tmp
Posted Mar 31, 2011 2:20 UTC (Thu) by k8to (guest, #15413) [Link]
2 - on Linux, at least (this is LWN) there is little advantage of tmpfs over a normal filesystem for tmp. Linux's filesystem layer is quite good about not needing to send out data to disk when unnecessary (a truly shortlived file may never see the disk at all), and for the longer lived or large file case you get perfectly reasonable behavior as well
/tmp and /var/tmp
Posted Mar 31, 2011 21:36 UTC (Thu) by jond (subscriber, #37669) [Link]
/tmp and /var/tmp
Posted Mar 31, 2011 12:57 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
And why shouldn't they?
/tmp and /var/tmp
Posted Mar 31, 2011 17:00 UTC (Thu) by vonbrand (guest, #4458) [Link]
Because /tmp is supposed to be off-limits for users, it being the place for system temporaries?
/tmp and /var/tmp
Posted Mar 31, 2011 17:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Sticky bit for directories was specifically invented for the world-writable /tmp. Also, where should user processes store their temporary data (for example, if a user opens a .tgz file in Nautilus)?
/home might be on a slow NFS link, so it's an incorrect answer.
/tmp and /var/tmp
Posted Mar 31, 2011 19:43 UTC (Thu) by vonbrand (guest, #4458) [Link]
The user temporary files are supposed to go in /var/tmp
/tmp and /var/tmp
Posted Mar 31, 2011 19:56 UTC (Thu) by martinfick (subscriber, #4455) [Link]
Where do you get that rationale from? The FHS does not think so:
The /tmp directory must be made available for programs that require temporary files. Programs must not assume that any files or directories in /tmp are preserved between invocations of the program. Tip Rationale
IEEE standard P1003.2 (POSIX, part 2) makes requirements that are similar to the above section. Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.
FHS added this recommendation on the basis of historical precedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard.
-
The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp.
Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp.
/tmp and /var/tmp
Posted Apr 1, 2011 15:55 UTC (Fri) by k8to (guest, #15413) [Link]
/tmp and /var/tmp
Posted Apr 1, 2011 17:30 UTC (Fri) by nix (subscriber, #2304) [Link]
(FWIW I too have never heard this before. /tmp is transient: /var/tmp is not. That's all.)
/tmp and /var/tmp
Posted Apr 2, 2011 15:15 UTC (Sat) by vonbrand (guest, #4458) [Link]
The compiler is not a "normal user", it is a system program (run by normal users under their UID, thus the sticky bit on /tmp).
/tmp and /var/tmp
Posted Apr 2, 2011 17:11 UTC (Sat) by mpr22 (subscriber, #60784) [Link]
1) I notice you're still not bothering to provide a citation for "/tmp is for the system and off-limits to ordinary applications".
2) In my world, the C compiler is an ordinary user application, so should use filesystems in the manner appropriate to ordinary user applications.
/tmp and /var/tmp
Posted Mar 31, 2011 13:43 UTC (Thu) by jschrod (subscriber, #1646) [Link]
In my world, if one uses applications that place there temporary files in /tmp and produce several GBs of them, it is surely *not* gross user incompetence if one decides not to spend one's time trying to detect how each and every of these apps can be persuaded to place their temporary files somewhere else. Instead one just gives /tmp more space. In my world, this is called pragmatic. Maybe you've heard of that term, but with your quick judgement of others, there is some doubt about that.
Maybe that information is new, but setting aside a few hundred GBs of disk space for /tmp is not really a problem with today's disk sizes. The 90s are over, really. And in no way that stops /tmp from being purged at reboot time.
Btw, if I would really clean out every day all /tmp files not accessed in a day, my desktop would not function any more. /tmp cleaning while user sessions are active needs more care than such coarse treatments; it needs blacklists, and most often also longer retention times.
/tmp and /var/tmp
Posted Apr 1, 2011 21:23 UTC (Fri) by Wol (subscriber, #4433) [Link]
BUT it *defaults* to "half available ram".
I got bitten by this when I put /var/tmp into tmpfs on gentoo, and then wondered why OpenOffice wouldn't compile :-)
I always set swap to (at least) twice available ram, which on my system is 32Gb (kernel 2.4 proved that the "twice ram" rule was NOT obsolete, and nobody has yet given me any reason to believe things have changed since then).
I think my tmpfs partitions are all set to about 10-16Gb in size. They're all fine. If you use enough space on the partition, it will simply spill into swap.
Cheers,
Wol
/tmp and /var/tmp
Posted Apr 2, 2011 14:28 UTC (Sat) by dtlin (subscriber, #36537) [Link]
/tmp and /var/tmp
Posted Apr 2, 2011 23:05 UTC (Sat) by Wol (subscriber, #4433) [Link]
But with 8Gb of ram, my system hardly ever swaps, even with /tmp as tmpfs.
However, portage occasionally chews up large amounts of temporary space. Compiling OOo, it recommends you have 10Gb of disk space free in /var/tmp/portage. Chances are, if anything ever gets flushed to swap, it'll never be wanted again, which is why I stick it in tmpfs rather than have it chew up real space in a real partition.
And with 1.5Tb disk across two drives, why should I care about losing 32Gb to swap? :-) It's there if it's needed - which it hardly ever is.
Cheers,
Wol
You 100% right - and still wrong :-)
Posted Apr 3, 2011 14:59 UTC (Sun) by khim (subscriber, #9252) [Link]
Yes, if you're constantly swapping your tmpfs you are slowing everything down. But more often then not it's not the case. 80/20> rules is valid for temporary files too. Most temporary files are accessed rarely, but few are accessed constantly - and they don't ever hit the disk with tmpfs. I know that incremental Chromium build is faster on tmpfs then on real fs if you have beefy system (16GB of RAM, 100GB of temporary files in tmpfs).
Introducing /run
Posted Mar 31, 2011 13:29 UTC (Thu) by jschrod (subscriber, #1646) [Link]
Introducing /run
Posted Mar 30, 2011 19:27 UTC (Wed) by dowdle (subscriber, #659) [Link]
Introducing /run
Posted Mar 30, 2011 19:45 UTC (Wed) by Trelane (subscriber, #56877) [Link]
Introducing /run
Posted Mar 30, 2011 19:48 UTC (Wed) by einstein (guest, #2052) [Link]
+1 funny
Introducing /run
Posted Mar 30, 2011 21:26 UTC (Wed) by teknohog (guest, #70891) [Link]
Introducing /run
Posted Mar 31, 2011 13:26 UTC (Thu) by jubal (subscriber, #67202) [Link]
No-one stops you from using /run/lola/run, which is also a little bit less convoluted. (A great film, that.)
Introducing /run
Posted Mar 30, 2011 20:12 UTC (Wed) by neilbrown (subscriber, #359) [Link]
mdadm really needs somewhere that persists from early boot. I tried /lib/init/rw first but that is Debian only and doesn't exist before '/' is mounted. I ended up sticking it in /dev/.mdadm but I really hated doing that. I don't believe in hidden directories any more than I believe in keeping secrets.
But /run/mdadm is the perfect answer.
Thanks.
Introducing /run
Posted Mar 30, 2011 22:33 UTC (Wed) by hmh (subscriber, #3838) [Link]
But now we can all work on /run. It is better that way, indeed.
Introducing /run
Posted Mar 30, 2011 20:43 UTC (Wed) by pyellman (guest, #4997) [Link]
Introducing /run
Posted Mar 30, 2011 20:58 UTC (Wed) by jrn (subscriber, #64214) [Link]
Introducing /run
Posted Mar 30, 2011 21:03 UTC (Wed) by nix (subscriber, #2304) [Link]
Machines were small in those days. 'runtime' uses four more bytes than 'run'. It may be that simple.
Introducing /run
Posted Mar 30, 2011 21:43 UTC (Wed) by drag (guest, #31333) [Link]
Try typing /etc /etc /etc /etc as fast as you can.
Now try it again with /et_cetera :)
Introducing /run
Posted Mar 30, 2011 22:16 UTC (Wed) by andrel (guest, #5166) [Link]
Introducing /run
Posted Mar 30, 2011 22:44 UTC (Wed) by drag (guest, #31333) [Link]
Anyways... /runtime is no more illustrative of the purpose of the directory then /run.
Introducing /run
Posted Mar 31, 2011 2:44 UTC (Thu) by pyellman (guest, #4997) [Link]
Introducing /run
Posted Mar 31, 2011 21:39 UTC (Thu) by jond (subscriber, #37669) [Link]
Introducing /run
Posted Mar 31, 2011 2:32 UTC (Thu) by pyellman (guest, #4997) [Link]
Introducing /run
Posted Mar 30, 2011 22:08 UTC (Wed) by josh (subscriber, #17465) [Link]
Introducing /run
Posted Mar 30, 2011 23:51 UTC (Wed) by nicooo (guest, #69134) [Link]
/var/run /runtime:)
Introducing /run
Posted Mar 31, 2011 19:49 UTC (Thu) by vonbrand (guest, #4458) [Link]
Re creat(2), I head a story sometime that the length of identifiers in the assembler was limited to 6, and that the compiler added a '_' in front of user identifiers to distiguish them from all sort of internal names used by the compiler and assembler (that was still that way with the C compiler in BSD 4.2 I used around 1985...), thus _creat at 6 characters, user-visible name creat with 5.
Introducing /run
Posted Mar 31, 2011 20:19 UTC (Thu) by dark (guest, #8483) [Link]
The length limit of 6 leaves just enough space for a colon and a tab, and then the code after the label aligns with all the other code.I don't know if that's the actual reason :)
Introducing /run
Posted Apr 1, 2011 17:32 UTC (Fri) by nix (subscriber, #2304) [Link]
Introducing /run
Posted Mar 30, 2011 21:09 UTC (Wed) by martinfick (subscriber, #4455) [Link]
The root directories are common directories that everyone familiar with unix should know, these are not obscure directories that you see once while investigating a deep application sub directory and wonder what it is. It makes sense to make the common easier for the experienced users and not the newcomers. Newcomers will ask once and then remember, in the mean time, the rest of us can benefit from short simple directory listings and paths. This is not elitism, this is simply better usability.
Introducing /run
Posted Mar 30, 2011 22:59 UTC (Wed) by dskoll (subscriber, #1630) [Link]
+1
I hate the occasional times I have to use a Windoze box and deal with monstrosities like C:\Program Files\Some Stupid Vendor Name\Some Huge Directory Name
And in my (mercifully) brief encounter with Mac OS X, I was similarly disgusted by its reworking of the standard UNIX directory layout into a verbose user-friendly [sic] horror.
Introducing /run
Posted Mar 31, 2011 6:04 UTC (Thu) by frazier (guest, #3060) [Link]
Introducing /run
Posted Mar 31, 2011 16:40 UTC (Thu) by zlynx (guest, #2285) [Link]
You've got to make sure TRIM is on and 8.3 names are off and last-accessed is off and you might like to tweak the memory buffers if you've got gobs of RAM.
With 8.3 names off, C:\program~1 fails to work, but at least NT stops reminding me of DOS.
Introducing /run
Posted Mar 30, 2011 21:29 UTC (Wed) by janfrode (subscriber, #244) [Link]
/runtime would have been much clearer.
Introducing /run
Posted Mar 30, 2011 22:06 UTC (Wed) by neilbrown (subscriber, #359) [Link]
(and just incase the irony is lost on anyone... I'm very glad that decision was just made and implemented without fuss, and I don't care what the name is as long as it doesn't start with '.').
Introducing /run
Posted Mar 30, 2011 21:38 UTC (Wed) by cmccabe (guest, #60281) [Link]
If you're using a novice-friendly environment like Ubuntu, Android, a set-top box, Meego, or whatever, the root directory will be hidden from you, and you won't have to worry about what /dev/hpet is, or /usr/lib64, or any of that stuff.
Longer path names just inconvenience the knowledgeable people without providing any corresponding gain for the novices.
Introducing /run
Posted Mar 31, 2011 2:42 UTC (Thu) by pyellman (guest, #4997) [Link]
For the record, I have introduced (or tried to introduce) Linux to a number of new users, generally from the Microsoft but some from the Apple world. Without exception, they have found the cryptic naming "conventions" for the root directory to be off-putting. Their displeasure only deepens when they are offered an explanation, and they adopt a genuine scowl when told the blunt truth: because the programmers who built the system prefer it that way.
I would venture that the cryptic root naming convention is the most immediate, visible, and universal barrier to entry for potential new Linux users. The sad part is, it doesn't have to be so.
Introducing /run
Posted Mar 31, 2011 11:24 UTC (Thu) by Seegras (guest, #20463) [Link]
> immediate, visible, and universal barrier to entry for potential new Linux > users. The sad part is, it doesn't have to be so.
You're very wrong. Because for a non-english speaker "bin" is just as alien as "binaries".
And if you don't want to go there, but l10n everything, you'll end up in a _terrible_ mess. See Windows, some fuckwits did that: "Program Files" and "Programme" and "Logiciel".
Cheers
Seegras
Introducing /run
Posted Mar 31, 2011 13:46 UTC (Thu) by zzxtty (guest, #45175) [Link]
Introducing /run
Posted Mar 31, 2011 13:50 UTC (Thu) by Trelane (subscriber, #56877) [Link]
Introducing /run
Posted Mar 31, 2011 16:32 UTC (Thu) by martinfick (subscriber, #4455) [Link]
I for one am reminded with many reasons any time I touch a windows (rare) PC, why I don't like it. Long untraversable (and weirdly hidden and tangled) paths which seem different on every windows version are one of the reasons. GUIs seem of no help to me to understand the layout either since each GUI twists and pretends the paths start at different roots.
So, you may believe that newbies understand long names better, but I suspect that what really happens is that nobody understands them. So, if the only way you can make a newbie as smart as an expert is by making the expert dumb, perhaps you have not really gained anything?
But again, read the previous posts. It is not about old gurus or being harder to type. It is about being able more easily read things, to visualize and remember a whole directory structure in one's head fairly easily. It's about making problems smaller and more easy to comprehend, more local. Your PC is not the WWW, it should not need long global directory names to separate itself from the rest of the PCs on the internet.
Keep the simple things simple. Yes, "simple", not "dumbed down". Assume (and enable) some level of competence and you will be rewarded with it. Assume idiots (and prevent progress) and you will get...
Introducing /run
Posted Mar 31, 2011 22:29 UTC (Thu) by cmccabe (guest, #60281) [Link]
> sensible....
> I would venture that the cryptic root naming convention is the most
> immediate, visible, and universal barrier to entry for potential new Linux
> users. The sad part is, it doesn't have to be so.
Doesn't MacOS have most of the same top-level directories as Linux? And isn't MacOS the operating system that user interface gurus love to go on and on about? Go away, troll.
Introducing /run
Posted Apr 1, 2011 0:04 UTC (Fri) by pyellman (guest, #4997) [Link]
>Doesn't MacOS have most of the same top-level directories as Linux?
No, as it turns out, it really doesn't. http://osxdaily.com/2007/03/30/mac-os-x-directory-structu.... It seems Apple has retained many of the directory names/labels, some apparently for "historical" purposes, but that in a number of key cases they also have other directories with similar functions but more informative labels.
In any case, I wasn't criticizing the existing names of root-level directories, as those would obviously be painful to change, but merely noting that an opportunity to provide a more informative name for a NEW top-level directory had been passed up. Make sure you know for what reason you're calling someone a troll or else you will provide a clear opportunity for someone to point out that you're an asshole.
>And isn't MacOS the operating system that user interface gurus love to go on and on about?
Oh, hell, I don't know; I guess so. I don't pay much attention to the MacOS crowd.
Introducing /run
Posted Apr 1, 2011 18:15 UTC (Fri) by cmccabe (guest, #60281) [Link]
Let me just rewind a bit. You said that:
> I would venture that the cryptic root naming convention is the most
> immediate, visible, and universal barrier to entry for potential new Linux
> users. The sad part is, it doesn't have to be so.
Yet MacOS has the same naming convention (except it doesn't have a /lib directory.) Somehow, nobody has found it to be an "immediate, visible and universal barrier to entry" for MacOS.
Thanks for the explanation
Posted Mar 30, 2011 22:36 UTC (Wed) by david.a.wheeler (guest, #72896) [Link]
Changing old specs is just fine, as long as there's a reason for it. I hope that FHS adds this (and at least something about libexec).
Thanks for the explanation
Posted Mar 30, 2011 23:41 UTC (Wed) by roblucid (guest, #48964) [Link]
Thanks for the explanation
Posted Mar 31, 2011 21:42 UTC (Thu) by jond (subscriber, #37669) [Link]
Thanks for the explanation
Posted Mar 31, 2011 11:38 UTC (Thu) by Seegras (guest, #20463) [Link]
As far as I can see libexec serves mostly to annoy sysadmins so they have to search for "updatedb" there... ;) Or am I wrong?
Thanks for the explanation
Posted Mar 31, 2011 12:26 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Thanks for the explanation
Posted Apr 21, 2011 13:23 UTC (Thu) by Seegras (guest, #20463) [Link]
That is not a case for libexec. That is a case for NOT having any libexec whatsoever.
Thanks for the explanation
Posted Apr 21, 2011 13:40 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Introducing /run (a Filesystem Hierarchy Standard perspective).
Posted Mar 31, 2011 0:02 UTC (Thu) by rusty (guest, #26) [Link]
As coeditor for FHS 2.2 and 2.3 (the last one before the LSB included it), I thought it might be worth commenting. That was 10 years ago, so I can't speak for the FHS today.The FHS 2.3 states "Distributions should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability." I think this bar has been fairly convincingly met for this case.
Note also that many of the aims of FHS, such as allowing /usr to be read only or sharing it across machines, are quaint by today's standards, and are not possible in major modern Linux distributions. But changing standards fast makes for very unhappy users, so legacy remains.
Cheers,
Rusty.
What Do We Want? LWN Supporter Subscription!
When Do We Want it? Um... soon... please?
Introducing /run (a Filesystem Hierarchy Standard perspective).
Posted Mar 31, 2011 6:26 UTC (Thu) by rodgerd (guest, #58896) [Link]
Introducing /run (a Filesystem Hierarchy Standard perspective).
Posted Mar 31, 2011 8:29 UTC (Thu) by rleigh (guest, #14622) [Link]
Regards,
Roger
Introducing /run
Posted Mar 31, 2011 1:53 UTC (Thu) by bk (guest, #25617) [Link]
However, I think /run makes sense. However we should now get rid of /proc. Probably /dev as well, since devices cannot be assumed to be static.
So we will have /run/proc and /run/dev and we are -1 for net top level directories. Sounds like a win.
Introducing /run
Posted Mar 31, 2011 2:18 UTC (Thu) by neilbrown (subscriber, #359) [Link]
The connection is probably not obvious but your observations lead me to the thought that the next "logical" step is for '/' to be a tmpfs filesystem (the same one that initramfs is loaded into - no need for pivot root)./run, /dev, and maybe /tmp are just subdirectories of '/'.
/bin, /etc, /usr, /var are all distinct mount points... probably --bind mount points. e.g
mkdir /root mount LABEL=rootfs /root for dir in bin sbin etc var lib do mkdir /$dir ; mount --bind /root/$dir /$dir doneThis means there is just one tmpfs filesystem with all the important stuff, and it is harder for rogue sysadmins to put extra non-standard things in / :-)
Introducing /run
Posted Mar 31, 2011 11:42 UTC (Thu) by Seegras (guest, #20463) [Link]
That only makes sense for you initrd-guys.
Introducing /run
Posted Mar 31, 2011 19:15 UTC (Thu) by lindi (subscriber, #53135) [Link]
pivot_root has not been used for quite some time. The "run-init" binary from klibc just mounts your hdd over / and chroots to it:
/* Overmount the root */
if (mount(".", "/", NULL, MS_MOVE, NULL))
return "overmounting root";
/* chroot, chdir */
if (chroot(".") || chdir("/"))
return "chroot";
/* Open /dev/console */
if ((confd = open(console, O_RDWR)) < 0)
return "opening console";
dup2(confd, 0);
dup2(confd, 1);
dup2(confd, 2);
close(confd);
/* Spawn init */
execv(init, initargs);
Introducing /run
Posted Apr 1, 2011 17:37 UTC (Fri) by nix (subscriber, #2304) [Link]
Seems a bit of an omission.
(busybox's switch_root has never had this problem.)
Introducing /run
Posted Jan 20, 2012 20:15 UTC (Fri) by smurf (subscriber, #17840) [Link]
Notice the MS_MOVE up there? This means that the source directory is moved there, thus the old root is (lazily) unmounted.
Unmounting a tempfs causes the files to get freed.
So in fact there is no problem.
Introducing /run
Posted Jan 26, 2012 18:19 UTC (Thu) by nix (subscriber, #2304) [Link]
Inspecting /proc/self/mounts should show you this as well: both mounts are still shown, mounted in the same place.
Introducing /run
Posted Mar 31, 2011 7:31 UTC (Thu) by Wummel (subscriber, #7591) [Link]
This reminds me of djb's /service directory from the daemontools. Nice to see that this idea of daemontools comes back to life after so many years.
Ah, DJB...
Posted Apr 3, 2011 15:14 UTC (Sun) by khim (subscriber, #9252) [Link]
DJB has a lot of great ideas. Sadly they are usually tightly intermixed with bunch of insane ideas so they tend not to gain traction till someone reinvents them years later.
Next Step...
Posted Mar 31, 2011 9:27 UTC (Thu) by ldo (guest, #40946) [Link]
Creating /share as an alternative to /usr/share. Why? So /usr/share/zoneinfo can be moved to /share/zoneinfo. Why? So that /etc/localtime can become a symlink, instead of a copy of a timezone file. Why? So that ls -l /etc/localtime will show you at a glance what your system timezone setting is.
Next Step...
Posted Mar 31, 2011 11:06 UTC (Thu) by rleigh (guest, #14622) [Link]
Regards,
Roger
Next Step...
Posted Mar 31, 2011 23:30 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Next Step...
Posted Apr 1, 2011 17:44 UTC (Fri) by hmh (subscriber, #3838) [Link]
Next Step...
Posted Apr 1, 2011 17:48 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Besides, "/usr on a separate disk" is still fairly common.
Next Step...
Posted Apr 2, 2011 16:32 UTC (Sat) by rleigh (guest, #14622) [Link]
Having a unified / and /usr isn't a new concept. Debian GNU/Hurd was doing this for years, with a /usr -> / symlink. It won't take much work to get this working on GNU/Linux. The main thing is finding and eliminating duplicate paths which would be overwritten; most of the duplicates are workarounds due to the split in the first place.
It's very common for people to have a knee-jerk negative reaction to this: after all, it's a radical departure from what we've been used to for decades. However, please do take the time to consider what you have gained from a separate /usr. For the vast majority of cases, nothing is gained other than needless complexity.
Most of the historical reasons for having the split are long gone. Sharing /usr between machines makes zero sense when you are using a modern package manager. Having a separate /usr for booting no longer matters now we have a capable initramfs which sets up the system sufficiently to allow any filesystem to be mounted: we can just mount / containing /usr directly; previously it was not always possible to do this if you needed to e.g. start up RAID arrays, discover LVM volume groups, bring up networking etc. Previously, you needed to do this using programs on the root filesystem as part of the startup sequence. Today, the initramfs does all of this. Now we have /run [I implemented this for Debian over the last two days in base-files and initscripts; should be available very soon] we are looking much nearer having a read-only / by default. It's common to have a read-only /usr; now you'll be able to have a read-only / *including* /usr.
Regarding top-level namespace pollution, most of the directories are duplicates, and those that are not still logically fit.
Regards,
Roger
Next Step...
Posted Apr 2, 2011 16:41 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
First, why do I need "/include"??? A language-specific directory on the top level? "/games" is equally stupid.
Oh, and how about /amd64-mingw32msvc, /arm-linux-gnueabi or /i586-mingw32msvc? Won't it be lovely to have them on the top level?
What we really need is consolidation of everything under ONE directory. I'd better move /bin, /sbin, /lib TO /usr if I had my way. Unfortunately, it's too deeply ingrained by now in all sorts of applications.
Think about it for a second. Imagine that you'd have a Linux with /etc, /home, /var, /usr in the top directory. Maybe also /system for sysfs, procfs and runtime directories. Won't it be easier to manage and use?
Next Step...
Posted Apr 2, 2011 17:51 UTC (Sat) by rleigh (guest, #14622) [Link]
The individual extra paths are purely cosmetic. That's really missing the point of why a separate /usr is bad and/or unnecessary. And by separate, I mean separately mountable.There's a significant cost to having a separate /usr. That cost is having some parts of the system unavailable before it is mounted, which makes the system have to go through complex contortions to actually start up.
Consider the NSS modules under /lib/libnss*.so used by the eglibc resolver. They may have dependencies on other libraries. Some of the LDAP modules have depend on libraries in /usr e.g. cryto libraries. If that module is needed to bring up the system, all those libraries must be moved to /lib, and any other data they need from /usr must be brought into the root.
Also consider eglibc itself; the locale data and other parts are found under /usr. If you use any of these facilities before /usr is mounted, it can break in "interesting" ways.
Those are just two examples. There's plenty more. The point is that it's complex, fragile, and makes some things incredibly hairy, and other things not possible at all.
These issues go away when you don't have a separate /usr. If you no longer have a separate / and /usr (i.e. mounting the roofs gets you both), then you have to question why you have /usr at all. Seriously, why? What advantages does it give you? It the cost/benefit worth it? I've spent some time thinking about the issue--you can see a link to my thoughts on the matter elsewhere on this page. Unifying / and /usr is a logical consequence of this.
An important concept to grasp is that on a modern package-managed distribution, / and /usr are not separable, and in fact have never been separable. They exist as a managed whole, and it is not possible to use or upgrade/maintain one without the other.
Regards, Roger
Next Step...
Posted Apr 2, 2011 18:12 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Your argument is incredibly weak. If you need LDAP for your system to mount /usr then you definitely doing something wrong and you just should make sure that /usr is available before LDAP is needed. And uniting / and /usr won't give you ANYTHING, since in this case you won't even have the final / if LDAP is not available.
Besides, namespace pollution is a reason in itself to avoid throwing some extra stuff to /.
Next Step...
Posted Apr 4, 2011 2:38 UTC (Mon) by hmh (subscriber, #3838) [Link]
It is very unlikely to fly until RO / becomes a reality. And unlike /run,
since it has been recently rejected, any attempts to get this deployed without getting most of the issues addressed are likely to backfire very nastly.
And you cannot have "no /usr" if you don't solve this one first, as all reasons for rejecting it are also valid for "no /usr".
2. no /usr: an EXTREMELY HARD sell. It causes a major mess on / and to my knowledge it will give us no strong technical advantages at all. It needs to wait for (1) above to be resolved, anyway.
Next Step...
Posted Apr 13, 2011 11:53 UTC (Wed) by robbe (guest, #16131) [Link]
> duplicates, and those that are not still logically fit.
Maybe get rid of cruft like /usr/{games,src} first? They have no reason to live.
Next Step...
Posted Apr 2, 2011 14:51 UTC (Sat) by pr1268 (subscriber, #24648) [Link]
While we're at it, why not introduce "/Program Files"?
/Ducks for cover
/Realizes April Fools' was one day ago
Next Step...
Posted Apr 2, 2011 22:58 UTC (Sat) by mezcalero (subscriber, #45103) [Link]
Think a bit about this, let it sink in. It's much nicer to symlink the root /bin, /sbin, /lib directories into /usr, then the other way round.
Next Step...
Posted Apr 3, 2011 21:51 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
However, here's the next question. If we get rid of separately-mounted /usr then we should as hell have something to replace it.
The current initramfs-based infrastructure just doesn't cut it (even in Dracut). It's way too complex to manage. What if I want to have a LDAP client in initramfs?
Hm. Why not treat initramfs as a small separate installation?.. It can even be managed using chroot'ed package managers. Hmmm...
Next Step...
Posted May 4, 2011 22:33 UTC (Wed) by nix (subscriber, #2304) [Link]
It requires only one change to early boot: the initramfs needs to find and mount /usr as well as /. Since it's already finding /, this is unlikely to be remotely problematic: it can figure out where to find it by consulting the real /etc/fstab on the / it just mounted, as well.
I think I'll rejig my system this way and see what breaks.
Introducing /run
Posted Mar 31, 2011 13:53 UTC (Thu) by jcm (subscriber, #18262) [Link]
* Who is "we"? Is "we" really "the systemd developers", because that's a small set.
* Was there any attempt to raise this as LFS prior to making the change?
I know the latter has been done retrospectively at least.
Jon.
Introducing /run
Posted Mar 31, 2011 20:36 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
You repeatedly keep saying LFS but you mean FHS and FHS explicitly allows distributions to add top level directories as required and a bug report has been filed against FHS asking for a change (although it hasn't been updated since 2004) and the co-author of the standard has been positive about this change right here in the same thread. In other words, no reason to complain.
Introducing /run
Posted Mar 31, 2011 20:41 UTC (Thu) by jcm (subscriber, #18262) [Link]
Jon.