Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 361349 - Use of /run
Summary: Use of /run
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Highest blocker with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
URL: https://lwn.net/Articles/436012/
Whiteboard:
Keywords:
: 361693 414719 439030 (view as bug list)
Depends on: 421839
Blocks: 365679 367949 380929 396003 409921 415987 484442
  Show dependency tree
 
Reported: 2011-03-30 18:24 UTC by Andrew John Hughes
Modified: 2019-04-29 08:23 UTC (History)
21 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
add-run-directory.patch (add-run-directory.patch,273 bytes, patch)
2011-06-19 19:50 UTC, William Hubbs
Details | Diff
fix-rundir.patch (fix-rundir.patch,517 bytes, patch)
2011-09-05 21:31 UTC, William Hubbs
Details | Diff
fix-rundir.patch (fix-rundir.patch,772 bytes, patch)
2011-09-06 02:25 UTC, William Hubbs
Details | Diff
migrate-run (migrate-run,539 bytes, text/plain)
2011-10-10 04:52 UTC, William Hubbs
Details
patch for baselayout-2.1 to create /run (baselayout-2.1-r1.ebuild.patch,206 bytes, patch)
2012-05-15 11:15 UTC, Samuli Suominen (RETIRED)
Details | Diff
Patch #2 for baselayout (revision bump) (foo.patch,150 bytes, text/plain)
2012-05-15 12:48 UTC, Samuli Suominen (RETIRED)
Details
Create /run from baselayout ebuild (revision bump for it) (foo.patch,410 bytes, patch)
2012-05-15 12:49 UTC, Samuli Suominen (RETIRED)
Details | Diff
More complex check for /run (foo.patch,803 bytes, patch)
2012-05-16 05:18 UTC, Samuli Suominen (RETIRED)
Details | Diff
More complex check #2 (foo.patch,826 bytes, patch)
2012-05-16 05:22 UTC, Samuli Suominen (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew John Hughes 2011-03-30 18:24:24 UTC
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?
Comment 1 Lars Wendler (Polynomial-C) gentoo-dev 2011-03-30 21:05:05 UTC
+1 from my side as it seems to make sense.
Comment 2 SpanKY gentoo-dev 2011-03-30 21:15:20 UTC
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.
Comment 3 Tolga Dalman 2011-03-31 11:13:44 UTC
(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.
Comment 4 Amadeusz Żołnowski (RETIRED) gentoo-dev 2011-04-17 17:05:42 UTC
(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.
Comment 5 William Hubbs gentoo-dev 2011-04-17 17:26:14 UTC
(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
Comment 6 Amadeusz Żołnowski (RETIRED) gentoo-dev 2011-04-17 21:18:15 UTC
(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.
Comment 7 William Hubbs gentoo-dev 2011-04-17 23:44:40 UTC
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.
Comment 8 William Hubbs gentoo-dev 2011-04-18 15:14:52 UTC
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?
Comment 9 William Hubbs gentoo-dev 2011-05-03 16:37:30 UTC
Base-system, what is the status of this bug?

I think we need a new release of baselayout that creates this directory.

Thanks,

William
Comment 10 Doug Goldstein (RETIRED) gentoo-dev 2011-05-09 14:47:28 UTC
(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.
Comment 11 William Hubbs gentoo-dev 2011-05-09 22:46:20 UTC
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.
Comment 12 William Hubbs gentoo-dev 2011-05-09 22:50:06 UTC
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.
Comment 13 SpanKY gentoo-dev 2011-05-16 22:08:43 UTC
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.
Comment 14 William Hubbs gentoo-dev 2011-05-17 00:13:34 UTC
(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?
Comment 15 Matthias Schwarzott gentoo-dev 2011-05-19 04:39:54 UTC
For now (version 168) udev does fallback to /dev/.udev when /run is not existing.
Comment 16 William Hubbs gentoo-dev 2011-05-19 13:56:57 UTC
(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
Comment 17 William Hubbs gentoo-dev 2011-06-18 15:22:10 UTC
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
Comment 18 William Hubbs gentoo-dev 2011-06-19 19:50:07 UTC
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?
Comment 19 William Hubbs gentoo-dev 2011-06-21 16:41:49 UTC
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.
Comment 20 Fabio Erculiani (RETIRED) gentoo-dev 2011-07-03 16:09:50 UTC
It looks like /run isn't created anyway (with the patch at #19).
I guess that patch is not enough.
Comment 21 William Hubbs gentoo-dev 2011-07-21 16:50:10 UTC
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?
Comment 22 William Hubbs gentoo-dev 2011-09-05 20:55:27 UTC
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
Comment 23 William Hubbs gentoo-dev 2011-09-05 21:31:25 UTC
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
Comment 24 William Hubbs gentoo-dev 2011-09-06 02:25:24 UTC
Created attachment 285681 [details, diff]
fix-rundir.patch

This patch might be a better one because it only creates /run on linux
systems.
Comment 25 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-09-06 06:53:56 UTC
(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.
Comment 26 William Hubbs gentoo-dev 2011-09-06 07:12:54 UTC
(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.
Comment 27 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-09-06 07:46:45 UTC
(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.
Comment 28 SpanKY gentoo-dev 2011-09-30 17:30:45 UTC
(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
Comment 29 William Hubbs gentoo-dev 2011-10-09 17:18:07 UTC
(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.
Comment 30 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-10-09 18:13:17 UTC
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.
Comment 31 SpanKY gentoo-dev 2011-10-09 19:07:10 UTC
(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/.
Comment 32 William Hubbs gentoo-dev 2011-10-09 20:13:36 UTC
(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 33 SpanKY gentoo-dev 2011-10-09 21:15:54 UTC
Comment on attachment 277557 [details, diff]
add-run-directory.patch

this has been merged
Comment 34 SpanKY gentoo-dev 2011-10-09 21:19:50 UTC
(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
Comment 35 William Hubbs gentoo-dev 2011-10-09 21:50:40 UTC
(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?
Comment 36 SpanKY gentoo-dev 2011-10-10 01:45:31 UTC
(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.
Comment 37 William Hubbs gentoo-dev 2011-10-10 04:52:46 UTC
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?
Comment 38 SpanKY gentoo-dev 2011-10-10 18:44:04 UTC
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.
Comment 39 William Hubbs gentoo-dev 2011-12-10 01:18:13 UTC
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
Comment 40 William Hubbs gentoo-dev 2011-12-11 21:22:42 UTC
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
Comment 41 SpanKY gentoo-dev 2011-12-19 03:16:08 UTC
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
Comment 42 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2011-12-27 02:03:54 UTC
(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.
Comment 43 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-12-27 09:32:13 UTC
(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?
Comment 44 William Hubbs gentoo-dev 2011-12-28 15:54:37 UTC
(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. :-)
Comment 45 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2011-12-28 16:23:14 UTC
(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.
Comment 46 SpanKY gentoo-dev 2011-12-31 20:27:20 UTC
(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.
Comment 47 William Hubbs gentoo-dev 2012-01-05 13:58:43 UTC
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.
Comment 48 William Hubbs gentoo-dev 2012-01-05 14:02:14 UTC
(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.
Comment 49 William Hubbs gentoo-dev 2012-01-12 15:23:16 UTC
As of udev-177, /run is mandatory.

Vapier, what else do you need so that we can get /run supported in
baselayout?
Comment 50 William Hubbs gentoo-dev 2012-01-14 00:41:41 UTC
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?
Comment 51 Maxim Kammerer 2012-01-26 13:27:53 UTC
Shouldn't /dev/shm and /lib/rc/init.d be migrated to /run as well?
Comment 52 William Hubbs gentoo-dev 2012-01-26 21:47:33 UTC
(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.
Comment 53 William Hubbs gentoo-dev 2012-05-05 19:35:32 UTC
*** Bug 414719 has been marked as a duplicate of this bug. ***
Comment 54 Samuli Suominen (RETIRED) gentoo-dev 2012-05-14 19:44:01 UTC
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)
Comment 55 Samuli Suominen (RETIRED) gentoo-dev 2012-05-14 19:55:16 UTC
(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 :-(
Comment 56 William Hubbs gentoo-dev 2012-05-14 20:09:31 UTC
(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?
Comment 57 Samuli Suominen (RETIRED) gentoo-dev 2012-05-14 20:43:41 UTC
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)
Comment 58 Joost Ruis 2012-05-14 22:03:14 UTC
We all know that upstream avoids politics. 
Can we step over this and get it done?
Comment 59 William Hubbs gentoo-dev 2012-05-14 22:33:29 UTC
@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
Comment 60 Samuli Suominen (RETIRED) gentoo-dev 2012-05-15 11:15:30 UTC
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)
Comment 61 William Hubbs gentoo-dev 2012-05-15 12:42:05 UTC
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.
Comment 62 William Hubbs gentoo-dev 2012-05-15 12:47:47 UTC
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
Comment 63 Samuli Suominen (RETIRED) gentoo-dev 2012-05-15 12:48:03 UTC
Created attachment 311859 [details]
Patch #2 for baselayout (revision bump)
Comment 64 Samuli Suominen (RETIRED) gentoo-dev 2012-05-15 12:49:58 UTC
Created attachment 311861 [details, diff]
Create /run from baselayout ebuild (revision bump for it)

@WilliamH: This should be it then
Comment 65 William Hubbs gentoo-dev 2012-05-15 15:49:37 UTC
The last patch looks ok to me.
I think I still would give it a day to see if there are any other
concerns.
Comment 66 William Hubbs gentoo-dev 2012-05-16 04:31:20 UTC
@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.
Comment 67 Richard Yao (RETIRED) gentoo-dev 2012-05-16 04:51:10 UTC
(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.
Comment 68 Samuli Suominen (RETIRED) gentoo-dev 2012-05-16 05:18:36 UTC
Created attachment 311949 [details, diff]
More complex check for /run

Something like this?
Comment 69 Samuli Suominen (RETIRED) gentoo-dev 2012-05-16 05:22:45 UTC
Created attachment 311959 [details, diff]
More complex check #2
Comment 70 Samuli Suominen (RETIRED) gentoo-dev 2012-05-16 05:57:54 UTC
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.
Comment 71 Dennis Schridde 2012-06-11 10:27:11 UTC
(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.
Comment 72 Amadeusz Żołnowski (RETIRED) gentoo-dev 2012-06-12 14:35:39 UTC
*** Bug 361693 has been marked as a duplicate of this bug. ***
Comment 73 Jeroen Roovers (RETIRED) gentoo-dev 2012-10-20 16:11:39 UTC
*** Bug 439030 has been marked as a duplicate of this bug. ***
Comment 74 Doug Goldstein (RETIRED) gentoo-dev 2013-09-05 22:36:45 UTC
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
Comment 75 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-09-05 23:20:02 UTC
(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.
Comment 76 Doug Goldstein (RETIRED) gentoo-dev 2013-09-13 12:27:41 UTC
(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.
Comment 77 Craig Andrews gentoo-dev 2016-07-20 16:34:46 UTC
(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.
Comment 78 Lars Wendler (Polynomial-C) gentoo-dev 2019-04-29 08:23:48 UTC
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.