LWN: Comments on "Introducing /run"

Introducing /run

karkhaz — Fri, 20 Oct 2017 15:56:07 +0000

Linus did it the right way by giving an interview about it

https://www.youtube.com/watch?v=5IfHm6R5le0

Introducing /run

poruid — Fri, 20 Oct 2017 09:42:19 +0000

In Dutch "oe" is pronounced as the German "U" and really, it sounds a lot better than the English "u".

Fixed link

rahulsundaram — Sun, 19 Oct 2014 02:01:01 +0000

I am disappointed but completely unsurprised to hear my prediction come true.

Fixed link

JesseW — Sun, 19 Oct 2014 01:22:14 +0000

The LF moved this, and broke the links -- it's now at: https://bugs.linuxfoundation.org/show_bug.cgi?id=718 . The bug is still in ASSIGNED state, with 19 comments, the most recent of which was on 2011-08-23.

Introducing /run

nix — Thu, 26 Jan 2012 18:19:18 +0000

This is not the case. mount("a","b"), no matter the flags, will never unmount "b". It just mounts "a" over the top of it: unmounting "a" will show you "b" still sitting there.

Inspecting /proc/self/mounts should show you this as well: both mounts are still shown, mounted in the same place.

Introducing /run

smurf — Fri, 20 Jan 2012 20:15:48 +0000

Just for the record:

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

Yaro — Sun, 19 Jun 2011 22:46:17 +0000

Yeah, I don't like Lennart, either. systemd can't properly init its way out of a paper bag (At least the "ancient" SysVInit can reliably make sure your partitions are mounted properly from the fstab. systemd couldn't even do that for me.) and PA breaks sound just about everywhere it's used.

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.

Next Step...

nix — Wed, 04 May 2011 22:33:51 +0000

That seemed cracked at first sight, but the more I think about it the more sense it makes. (I think SysV did something like it, too, but I don't have a SysV system nearby to check.)

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.

/tmp and /var/tmp

nix — Wed, 04 May 2011 21:36:32 +0000

KDE rebuilds those cache files at every startup anyway.

Introducing /run

nix — Wed, 04 May 2011 21:29:41 +0000

You think you're joking:

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.

Thanks for the explanation

rahulsundaram — Thu, 21 Apr 2011 13:40:46 +0000

You asked for a rationale and one has been provided. If you disagree, provide a alternative solution instead of naysaying. This is where FHS as a maintained standard would be useful. Unfortunately this isn't the case now.

Thanks for the explanation

Seegras — Thu, 21 Apr 2011 13:23:16 +0000

"As such in a simplified view libexecdir contents are more like bindir contents only that they don't appear in the user's path."

That is not a case for libexec. That is a case for NOT having any libexec whatsoever.

Next Step...

robbe — Wed, 13 Apr 2011 11:53:08 +0000

> Regarding top-level namespace pollution, most of the directories are
> 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...

hmh — Mon, 04 Apr 2011 02:38:01 +0000

1. /usr inside /: we have been through that recently enough in debian-devel. There were many objections, and it was rejected for the time being.

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

Cyberax — Sun, 03 Apr 2011 21:51:28 +0000

This is a bit nicer. I really hate all those extra folders in the root directory.

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

Ah, DJB...

khim — Sun, 03 Apr 2011 15:14:21 +0000

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.

You 100% right - and still wrong :-)

khim — Sun, 03 Apr 2011 14:59:17 +0000

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

/tmp and /var/tmp

Wol — Sat, 02 Apr 2011 23:05:02 +0000

:-)

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

Next Step...

mezcalero — Sat, 02 Apr 2011 22:58:44 +0000

Go the other way. Make /bin, /sbin, /lib and /lib64 symlinks to their counterparts in /usr. If you do, then suddenly /usr gets its original meaning back as "Unix System Resources". Because that's what it is going to be then: in /usr you find "The OS". And in / you will then only have a few top-level directories whose meaning is clearly bound to lifecycle properties, nothing else anymore.

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

Cyberax — Sat, 02 Apr 2011 18:12:58 +0000

Then one can unify /var and /. What if one needs Postfix running in order to use SMTP to get a one-time password for the system to boot? Or maybe /var/spool is necessary for CUPS to print out boot logs on a remote printer?

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

rleigh — Sat, 02 Apr 2011 17:51:52 +0000

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

/tmp and /var/tmp

mpr22 — Sat, 02 Apr 2011 17:11:39 +0000

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.

Next Step...

Cyberax — Sat, 02 Apr 2011 16:41:26 +0000

I gain at least a measure of order from /usr.

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

rleigh — Sat, 02 Apr 2011 16:32:32 +0000

Separate /usr is extremely common, and this isn't going to go away anytime soon. It will also never be possible to make the transition automatic: it could well require repartitioning in order to get a big enough root partition, or LV resizing etc. So having a unified / and /usr will only be possible to do on a fresh install. Initially, it will just be an option, and it won't be the default. But it will be /possible/.

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

/tmp and /var/tmp

vonbrand — Sat, 02 Apr 2011 15:15:02 +0000

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

Next Step...

pr1268 — Sat, 02 Apr 2011 14:51:41 +0000

While we're at it, why not introduce "/Program Files"?

/Ducks for cover
/Realizes April Fools' was one day ago

/tmp and /var/tmp

dtlin — Sat, 02 Apr 2011 14:28:49 +0000

Spinning disk filesystems try hard to keep data contiguous; swap does a relatively poorer job of it. So if you're constantly swapping your tmpfs, it's likely slower than if you just used a dedicated filesystem.

"Flame away!"

kleptog — Sat, 02 Apr 2011 12:28:05 +0000

Umm, couldn't you just provide the new libraries under a new name? There is a question of when to delete the old files, but that's why having parallel installs of different versions is a good idea.

/tmp and /var/tmp

Wol — Fri, 01 Apr 2011 21:23:15 +0000

tmpfs can cope with huge amounts of data no problem.

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

nicooo — Fri, 01 Apr 2011 20:48:05 +0000

The OpenBSD man page for hier makes the difference clearer.

/tmp and /var/tmp

dtlin — Fri, 01 Apr 2011 19:13:17 +0000

: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'.)

Introducing /run

cmccabe — Fri, 01 Apr 2011 18:15:11 +0000

I called you a troll because I genuinely did not see how anyone could hold the point of view you were espousing. Maybe I was a little bit too hasty.

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.

Next Step...

Cyberax — Fri, 01 Apr 2011 17:48:50 +0000

Absolutely there's going to be resistance. And for a good reason, the / namespace is already too polluted.

Besides, "/usr on a separate disk" is still fairly common.

Next Step...

hmh — Fri, 01 Apr 2011 17:44:36 +0000

It is not. But expect quite a lot of resistance in the Debian side. Unlike the addition of /run, which we wanted to do years ago, killing /usr is NOT going to be well received at all.

Introducing /run

nix — Fri, 01 Apr 2011 17:37:47 +0000

It doesn't take care to erase everything else in the initramfs beforehand? So it stays eating up memory forever?

Seems a bit of an omission.

(busybox's switch_root has never had this problem.)

Introducing /run

nix — Fri, 01 Apr 2011 17:32:10 +0000

Yes indeed. Levine mentions this in _Linkers and Loaders_, a book full of gold dust about ancient systems (and a lot of stuff applicable to new ones too).

/tmp and /var/tmp

nix — Fri, 01 Apr 2011 17:30:03 +0000

Uh, GCC dumps stuff in /tmp if you don't specify -pipe. Is the compiler something normal users shouldn't run now?

(FWIW I too have never heard this before. /tmp is transient: /var/tmp is not. That's all.)

/tmp and /var/tmp

nix — Fri, 01 Apr 2011 17:28:30 +0000

Oo, thanks, hadn't noticed that. It doesn't record the pathname anywhere, though, so collisions are quite likely. (Emacs and XEmacs encode the pathname in the autosave filename.)

/tmp and /var/tmp

k8to — Fri, 01 Apr 2011 15:55:52 +0000

If /tmp was not for users, then the sticky bit would not have been added to unix to specifically support /tmp for users.

Introducing /run

motk — Fri, 01 Apr 2011 03:59:22 +0000

There's always slackware if you want to live in 1999 Linuxland. Or NetBSD, perhaps.