Debian, Fedora and Ubuntu are switching to /run as a replacements for solutions such as /lib/init/rw (used on Debian & Gentoo) and hidden /dev directories when early run-time data needs to be stored before other directories are mounted. See https://lwn.net/Articles/436012/ Does Gentoo also plan to make this change?
+1 from my side as it seems to make sense.
there's really no point at this time. almost none of the programs quoted are utilized in Gentoo, and it kind of makes sense for udevd to leverage /dev considering it's managing it. as for openrc, its transitional handling of pre-/var mount works fine and isnt that big of a deal. as for the vast majority of packages, /var/{run,lock,etc...} should still be used, and the proposal keeps those paths working. so no, i dont see any point right now of jumping on the bandwagon.
(In reply to comment #2) > as for the vast majority of packages, /var/{run,lock,etc...} should still be > used, and the proposal keeps those paths working. I don't want to troll or start a flame-war, but I have to ask: Why ? I think adding a /run and symlinking /var/run and /var/lock to this path should be very easy. In fact, I think it's a great idea. > so no, i dont see any point right now of jumping on the bandwagon. Too bad.
(In reply to comment #2) > there's really no point at this time. almost none of the programs quoted are > utilized in Gentoo, and it kind of makes sense for udevd to leverage /dev > considering it's managing it. I think we no longer have much to say. Major distros are moving to /run and this directory will be assumed to exist. Better we prepare than fixing upcoming bugs. udevd will drop /dev/.udev soon or later. Another major software is Dracut which already supports /run/initramfs. Putting its stuff into /dev/.initramfs isn't very clear. In initramfs-time Dracut already uses /run and as a fall back it unmounts /run before switch to root and moves stuff to /dev/.initramfs. I'd like to avoid that. Please reconsider that. I can handle the problem if you all agree.
(In reply to comment #4) > (In reply to comment #2) > > there's really no point at this time. almost none of the programs quoted are > > utilized in Gentoo, and it kind of makes sense for udevd to leverage /dev > > considering it's managing it. > I think we no longer have much to say. Major distros are moving to /run and > this directory will be assumed to exist. Better we prepare than fixing > upcoming bugs. udevd will drop /dev/.udev soon or later. > Another major software is Dracut which already supports /run/initramfs. > Putting its stuff into /dev/.initramfs isn't very clear. In initramfs-time > Dracut already uses /run and as a fall back it unmounts /run before switch to > root and moves stuff to /dev/.initramfs. I'd like to avoid that. > Please reconsider that. I can handle the problem if you all agree. I tend to agree. Vapier, can you please reconsider this and do another release of baselayout-2 that creates the /run directory? Thanks much, William
(In reply to comment #4) > Please reconsider that. I can handle the problem if you all agree. Patch for OpenRC is ready, see bug #363971.
I am removing the dependency on 369371. It is related, but not a dependency since the patch for openrc on that bug is backward compatible.
Another thing that needs to happen for this transition is that /var/run and /var/lock should be linked to /run and /run/lock respectively. From the article it looks like the fc folks are going to initially use bind mounts for this but transition to symbolic links. How do you think we should do this?
Base-system, what is the status of this bug? I think we need a new release of baselayout that creates this directory. Thanks, William
(In reply to comment #9) > Base-system, what is the status of this bug? > > I think we need a new release of baselayout that creates this directory. > > Thanks, > > William I would agree, we'll need a new base-layout that contains this directory. We'll also need some tweaks in some init scripts to setup the bind mounts.
The modifications needed to the init scripts are already in openrc git. Once the new baselayout is out with the /run directory and openrc-0.8.3 is released, openrc will pick up the /run directory after it is created.
What do we need to bind mount? I believe I read somewhere that fedora wants to eventually use symbolic links, so we could do the same -- link /var/run to /run and /var/lock to /lock. That would be done in baselayout and there would be no need for bind mounts.
no, we dont need a baselayout to create this /run. i'm still not convinced of this cruft. openrc supports it if the user opts into it, then that's fine. but that doesnt mean baselayout should be doing it.
(In reply to comment #13) > no, we dont need a baselayout to create this /run. i'm still not convinced of > this cruft. openrc supports it if the user opts into it, then that's fine. > but that doesnt mean baselayout should be doing it. Vapier, please see comment #4, in particular the bit about udev. Eventually, udev will consider /run not existing to be a critical error and will not run. There are also other packages now, e.g. dracut, which support /run. The /run directory is not cruft, and eventually will not be optional. So which package should make the /run directory if not baselayout?
For now (version 168) udev does fallback to /dev/.udev when /run is not existing.
(In reply to comment #15) > For now (version 168) udev does fallback to /dev/.udev when /run is not > existing. The following is taken from the udev NEWS file for udev 168: "Udev logs a warning now if /run is not writable at udevd startup. It will still fall back to /dev/.udev, but this is now considered a bug." I would rather have the /run directory in place before upstream decides to not fall back to /dev/.udev. Thanks, William
I see that baselayout-2.0.3 was released without adding the /run directory. Can you please add /run and release 2.0.4? Thanks, William
Created attachment 277557 [details, diff] add-run-directory.patch This patch adds the /run directory to baselayout for linux systems. Mike, can you please applythis and do a new release?
the patch in the previous comment has been added to baselayout's svn. When the new baselayout is released there will be a /run directory, but the transition involving /var/{lock,run} has not started.
It looks like /run isn't created anyway (with the patch at #19). I guess that patch is not enough.
That patch will work for stages, but not for live systems. Mike, What is the best way to make sure /run gets created on live file systems?
Mike, what is your answer to my previous comment? The /run directory is becoming more important as time goes on; we need a new release of baselayout that adds this directory. Thanks, William
Created attachment 285671 [details, diff] fix-rundir.patch Mike, this is one way I've thought of adding this, but I need your opinion. Is this correct? If so, can you please do another baselayout release with this included? Thanks, William
Created attachment 285681 [details, diff] fix-rundir.patch This patch might be a better one because it only creates /run on linux systems.
(In reply to comment #24) > Created attachment 285681 [details, diff] > fix-rundir.patch > > This patch might be a better one because it only creates /run on linux > systems. Is there a way to make it mounted on tmpfs whenever available? I think that'd be better.
(In reply to comment #25) > Is there a way to make it mounted on tmpfs whenever available? I think that'd > be better. Not in baselayout. Baselayout should only create the /run directory. Mounting the tmpfs there is the responsibility of the init script system you are using (openrc, systemd, etc). Code exists in openrc to handle this, but it doesn't mount anything until the /run directory exists. The final step in the process is to get the /run directory created; that is why we need this change in baselayout.
(In reply to comment #26) > (In reply to comment #25) > > Is there a way to make it mounted on tmpfs whenever available? I think that'd > > be better. > > Not in baselayout. > > Baselayout should only create the /run directory. Mounting the tmpfs there is > the responsibility of the init script system you are using (openrc, systemd, > etc). > > Code exists in openrc to handle this, but it doesn't mount anything until the > /run directory exists. > > The final step in the process is to get the /run directory created; that is why > we need this change in baselayout. Ah, right, we're talking about plain baselay here; sorry.
(In reply to comment #26) in terms of migration, we can't really do it in any ebuild as running programs will have open file handles to things in /var/lock and /var/run. so the ebuilds will just contain a warning when they detect that /var/lock and /var/run are directories rather than symlinks to /run. if we wanted to do automatic miagration, we could tweak /etc/init.d/mount-ro to do something like: rm -rf /var/run && ln -s /run /var/run rm -rf /var/lock && ln -s /run/lock /var/lock
(In reply to comment #28) > (In reply to comment #26) > > in terms of migration, we can't really do it in any ebuild as running programs > will have open file handles to things in /var/lock and /var/run. so the > ebuilds will just contain a warning when they detect that /var/lock and > /var/run are directories rather than symlinks to /run. > > if we wanted to do automatic miagration, we could tweak /etc/init.d/mount-ro to > do something like: > rm -rf /var/run && ln -s /run /var/run > rm -rf /var/lock && ln -s /run/lock /var/lock I'm not sure you would want to do this inside openrc, because it will only be run on linux systems, and it will only need to be run once on each system.
BTW is there a good reason not to use /run on non-linux systems? I think it will be even more painful for apps to support another case like that.
(In reply to comment #29) we can install the migration script only for linux systems, and only when /run doesn't exist, otherwise remove it. on the next openrc upgrade, it would auto-clean itself. (In reply to comment #30) we're not going to dictate standards to other OS's, and i don't see any pain here at all. no package should be using paths to /run/ in place of /var/run/.
(In reply to comment #31) > (In reply to comment #29) > > we can install the migration script only for linux systems, and only when /run > doesn't exist, otherwise remove it. on the next openrc upgrade, it would > auto-clean itself. Maybe this is something we do at the ebuild level then and not in openrc's upstream git? > (In reply to comment #30) > > we're not going to dictate standards to other OS's, and i don't see any pain > here at all. no package should be using paths to /run/ in place of /var/run/. /run is linux-specific by design, so I agree. We are not going to put the /run directory on non-linux systems.
Comment on attachment 277557 [details, diff] add-run-directory.patch this has been merged
(In reply to comment #32) we could apply a patch to the mount-ro init.d script to do the migration in src_prepare, and then sed it out in pkg_postinst if /run exists
(In reply to comment #34) > (In reply to comment #32) > > we could apply a patch to the mount-ro init.d script to do the migration in > src_prepare, and then sed it out in pkg_postinst if /run exists That doesn't work if people don't have openrc installed in the first place, which can happen. Some how we need to do the migration in a way that is independent of the init scripts, or we need to write up a procedure for people to do it themselves. On a high level, this is what needs to happen for the migration as I see it. 1) stop programs that have files open in /var/{lock,run} 2) cp -a /var/lock /run;rm -rf /var/lock;ln -s /var/lock /run/lock 3) cp -a /var/run/* /run;rm -rf /var/run;ln -s /var/run /run 4) restart programs that opened files in /var/{lock,run}. How can we do this so that we do not affect openrc?
(In reply to comment #35) very few people are not using openrc. you can write up a section for the openrc migration guide if you like, but for the openrc users, we need to make this transparent.
Created attachment 289421 [details] migrate-run Mike, Thinking about it, I like the idea of a separate service for openrc to do this. This service is not complete because I'm not sure what to put in the dependencies, but, if we add this to openrc and install it in the boot runlevel, it would run when the system is shut down and perform the migration. Then we could remove it in a release or so. What would be best to put in the dependencies for this?
if you can get the depend() such that the init.d runs after everything else but before mount-ro, i'm fine with doing it this way. something like: after * before mount-ro but i'm not sure openrc is smart enough to handle that ... and i think that's a long standing complaint wrt the globs. people often times want to use the glob as the default, but then tweak the set for a few select init scripts.
Mike, openrc-0.9.7 now migrates /var/{lock,run} to symbolic links as part of the bootmisc script. I believe this is the last obstacle to getting the /run directory in baselayout-2.x, so can you please do a ~arch release of baselayout-2 that adds a "keepdir /run" or whatever is necessary to create /run on live filesystems? Thanks, William
Mike, there is another change that needs to happen some how in the new baselayout: When you build stages, instead of creating directories for /var/run and /var/lock, we need them to be symbolic links as follows: ln -s /run /var/run ln -s /run/lock /var/lock Thanks, William
we might need to adjust the mount perms. otherwise, screen doesn't work. $ screen -li Cannot make directory '/var/run/screen': Permission denied - mount -t tmpfs -o mode=0755,nosuid,nodev tmpfs /run + mount -t tmpfs -o mode=1777,nosuid,nodev tmpfs /run
(In reply to comment #41) > we might need to adjust the mount perms. otherwise, screen doesn't work. > > $ screen -li > Cannot make directory '/var/run/screen': Permission denied > > - mount -t tmpfs -o mode=0755,nosuid,nodev tmpfs /run > + mount -t tmpfs -o mode=1777,nosuid,nodev tmpfs /run No, unprivileged users should not be able to create files in /run. See this part of the FHS discussion: https://lists.linux-foundation.org/pipermail/fhs-discuss/2011-May/000252.html We need to create /var/run/screen on boot.
(In reply to comment #42) > (In reply to comment #41) > > we might need to adjust the mount perms. otherwise, screen doesn't work. > > > > $ screen -li > > Cannot make directory '/var/run/screen': Permission denied > > > > - mount -t tmpfs -o mode=0755,nosuid,nodev tmpfs /run > > + mount -t tmpfs -o mode=1777,nosuid,nodev tmpfs /run > No, unprivileged users should not be able to create files in /run. > > See this part of the FHS discussion: > https://lists.linux-foundation.org/pipermail/fhs-discuss/2011-May/000252.html > > We need to create /var/run/screen on boot. Hmm, time to add support for tmpfiles.d rather than reinventing the wheel?
(In reply to comment #43) > Hmm, time to add support for tmpfiles.d rather than reinventing the wheel? What is tmpfiles.d? Where is it created? I have seen nothing about it other than this comment. :-)
(In reply to comment #44) > (In reply to comment #43) > > Hmm, time to add support for tmpfiles.d rather than reinventing the wheel? > > What is tmpfiles.d? Where is it created? I have seen nothing about it other > than this comment. :-) http://0pointer.de/public/systemd-man/tmpfiles.d.html The idea is quite simple: 1) packages install tmpfiles.d files, 2) some service is started at boot, reads them and creates/cleans/santizies tmpfiles as requested by those files.
(In reply to comment #42) yeah, i realized this a few days later. granting world write access to this opens up the standard temp file vulnerabilities. symlink some pid files to random paths and i bet many daemons would clobber the destination without thinking twice. (In reply to comment #45) sadly, i think Michał might be right. there's no clean way to have the screen path be created only when needed (i.e. when app-misc/screen is installed). it probably also allows us to convert all `checkpath` usage over to tmpfiles.d.
I have moved all discussion of tmpfiles.d support to bug 396003. Also, /var/{lock,run} migration is disabled in openrc until tmpfiles.d support is added. @vapier: As I stated in my email to you, we need a baselayout that creates /run sooner than later; upstream udev now considers /run not existing to be a fatal error. This will go into affect as soon as udev-176 is released. So please tell us what else you need before you can release a baselayout that creates /run.
(In reply to comment #40) > Mike, > > there is another change that needs to happen some how in the new > baselayout: > > When you build stages, instead of creating directories for /var/run and > /var/lock, we need them to be symbolic links as follows: > > ln -s /run /var/run > ln -s /run/lock /var/lock > > Thanks, > > William This piece can wait until openrc with the /var/{lock,run} migration enabled hits stable.
As of udev-177, /run is mandatory. Vapier, what else do you need so that we can get /run supported in baselayout?
I am adjusting the importance and priority on this bug to reflect that it is blocking newer versions of udev. As I stated in comment #47, we do not need tmpfiles.d support at this point because the /var/run and /var/lock migration is disabled in openr. Can you please clarify what else you are waiting for or if there are any other issues that need to be resolved?
Shouldn't /dev/shm and /lib/rc/init.d be migrated to /run as well?
(In reply to comment #51) > Shouldn't /dev/shm and /lib/rc/init.d be migrated to /run as well? Possibly, but this is not the bug where those issues should be discussed. This bug is just here until we get a version of baselayout that creates the /run directory.
*** Bug 414719 has been marked as a duplicate of this bug. ***
Browsing all the comments and I can't find the actual reason why /run is still missing from default installations. It was created by something previously on my installation, but seems to be now missing. Anyway, this broke nearly every desktop wrt bug 415987 (sys-fs/udisks)
(In reply to comment #54) > Browsing all the comments and I can't find the actual reason why /run is > still missing from default installations. It was created by something > previously on my installation, but seems to be now missing. > > Anyway, this broke nearly every desktop wrt bug 415987 (sys-fs/udisks) Scratch that. UDisks2 will create the entire directory structure, /run/media/$user, on it's own by g_mkdir() But I would still prefer something else, like baselayout or openrc, to create the initial /run :-(
(In reply to comment #55) > Scratch that. UDisks2 will create the entire directory structure, > /run/media/$user, on it's own by g_mkdir() > But I would still prefer something else, like baselayout or openrc, to > create the initial /run :-( Technically baselayout should do this since this is part of the base filesystem layout. Right now, at least systemd and udev make the directory by using: mkdir -p "${ROOT}/run in pkg_postinst, and soon OpenRC itself will be doing this. It also looks like the newer versions of lvm2 need to be doing the same thing. Wouldn't it be better to do this in baselayout instead of having all of these packages create the directory?
Actually udisks:2 creates 'media' inside /run if it's missing but not the /run itself unfortunately So not having the directory breaks both GNOME and Xfce in ~arch if gnome-base/gvfs is built with USE="udisks udev" (recommended) instead of USE="gdu udev" (obsolete)
We all know that upstream avoids politics. Can we step over this and get it done?
@vapier: The /var/lock and /var/run symbolic links are the only things that can't be created yet because we do not have tmpfiles.d support complete in OpenRC. However, this does not prevent the creation of the /run directory. Also, for now, we create /run/lock directly in openrc once we mount the tmpfs. So, what else do you need so that we can get /run created in baselayout? Thanks, William
Created attachment 311853 [details, diff] patch for baselayout-2.1 to create /run I'll commit this is nobody objects within a day (or two)
You don't need to test for "${ROOT}"/run; just create it with mkdir -p like you are doing. Also this should be a revbump.
Actually you only want /run to be created on linux systems, so I would change the line to something like: use kernel_linux && mkdir -p "${ROOT}"/run
Created attachment 311859 [details] Patch #2 for baselayout (revision bump)
Created attachment 311861 [details, diff] Create /run from baselayout ebuild (revision bump for it) @WilliamH: This should be it then
The last patch looks ok to me. I think I still would give it a day to see if there are any other concerns.
@ssuominen: Another thing I thought about that you might want to do is add a check to pkg_postinst like this after you run the mkdir -p "${ROOT}"/run command. If "${ROOT}"/run is not a mounted tmpfs and we are on a linux system, there needs to be some kind of action taken -- either warn people that they need to reboot or try to mount a tmpfs. OpenRC takes care of mounting the tmpfs once you reboot, but I'm not sure what the best action is for baselayout if /run isn't a tmpfs in the meantime.
(In reply to comment #66) > @ssuominen: > Another thing I thought about that you might want to do is add a check > to pkg_postinst like this after you run the mkdir -p "${ROOT}"/run > command. > > If "${ROOT}"/run is not a mounted tmpfs and we are on a linux system, > there needs to be some kind of action taken -- either warn people that > they need to reboot or try to mount a tmpfs. > OpenRC takes care of mounting the tmpfs once you reboot, but I'm not > sure what the best action is for baselayout if /run isn't a tmpfs in the > meantime. We could mount a tmpfs at /run (if one is not already mounted) and advise the user to restart udev if the tmpfs at /run did not exist.
Created attachment 311949 [details, diff] More complex check for /run Something like this?
Created attachment 311959 [details, diff] More complex check #2
Done in =sys-apps/baselayout-2.1-r1. Run `diff -u baselayout-2.1.ebuild baselayout-2.1-r1.ebuild` to see the difference. It's quite simple.
(In reply to comment #70) > Done in =sys-apps/baselayout-2.1-r1. Run `diff -u baselayout-2.1.ebuild > baselayout-2.1-r1.ebuild` to see the difference. It's quite simple. Why did you use mkdir instead of dodir? I was searching for which package created /run on my system (it was missing somewhere else) and could not find it, because "q file /run" did not output anything, because no package actually owned the dir.
*** Bug 361693 has been marked as a duplicate of this bug. ***
*** Bug 439030 has been marked as a duplicate of this bug. ***
I've talked to some of the autoconf maintainers about providing a flag to specify the rundir as /run, instead of how many packages do localstatedir + "/run" and he was receptive but it requires a GNU Coding Standards change and acceptance from the automake guys. So I took the first step in asking for the GCS update, http://lists.gnu.org/archive/html/bug-standards/2013-09/msg00001.html
(In reply to Doug Goldstein from comment #74) > I've talked to some of the autoconf maintainers about providing a flag to > specify the rundir as /run, instead of how many packages do localstatedir + > "/run" and he was receptive but it requires a GNU Coding Standards change > and acceptance from the automake guys. So I took the first step in asking > for the GCS update, > http://lists.gnu.org/archive/html/bug-standards/2013-09/msg00001.html I'm not sure how GCS are detailed on stuff like that but it may be a good idea to explicitly require applications to create the /run structure they need. You also need to consider /run/lock and /var/lock since $rundir/lock will not work :). Though I'd rather make lockdir=/run so that we wouldn't have two application hierarchies in /run.
(In reply to Michał Górny from comment #75) > (In reply to Doug Goldstein from comment #74) > > I've talked to some of the autoconf maintainers about providing a flag to > > specify the rundir as /run, instead of how many packages do localstatedir + > > "/run" and he was receptive but it requires a GNU Coding Standards change > > and acceptance from the automake guys. So I took the first step in asking > > for the GCS update, > > http://lists.gnu.org/archive/html/bug-standards/2013-09/msg00001.html > > I'm not sure how GCS are detailed on stuff like that but it may be a good > idea to explicitly require applications to create the /run structure they > need. > > You also need to consider /run/lock and /var/lock since $rundir/lock will > not work :). Though I'd rather make lockdir=/run so that we wouldn't have > two application hierarchies in /run. Well since /run can and when its a tmpfs it does get cleared on reboot it doesn't make sense for an application to create a directory structure in there. Really a better solution is for the daemon/init script to create what it needs. Or to use a mechanism like tmpfiles.d. We are currently discussing /run/lock and /lock. I think we're leaning towards /run/lock and having it be mandated when /run is created, the thing that does that is responsible to make /run/lock. Just waiting on RMS to ACK --runstatedir for autoconf and it'll be ready. Eric Blake has put together the patches for autoconf 2.70 and gnulib. I've tried my hand for automake 2.0.
(In reply to Doug Goldstein from comment #76) > > Just waiting on RMS to ACK --runstatedir for autoconf and it'll be ready. > Eric Blake has put together the patches for autoconf 2.70 and gnulib. I've > tried my hand for automake 2.0. The change has been included in autoconf for release in 2.70. I've submitted bug 589248 requesting that runstatedir support be included in Gentoo's autoconf 2.69 package.
I think, /run is well established in Gentoo nowadays. Seeing that even the bugs that were blocked by this bug are all closed, I see no reason to keep this bug open any longer.
