Following suggestion in bug #361349, I am opening a this bug about possibly migrating /lib/rc/init.d (mounted as tmpfs at boot) and /dev/shm to /run.
This bug will follow migrating /lib/rc/init.d. WRT /dev/shm, I could create the directory, /run/shm, easily enough, but I believe /dev/shm is a glibc requirement, so before I do that I would need to know that glibc would use it.
Maybe I am missing something about /dev/shm (should this be a separate bug?), but /dev/shm should remain a link to /run/shm, no? Being the original tmpfs, other programs would expect to be able to use it, even if glibc doesn't (I know I wrote scripts that used /dev/shm).
I am working on a patch to migrate /lib/rc/init.d to /run. The comment about /dev/shm isn't related to OpenRC, so that will need to be another bug, but I don't see it moving to /run.
I have a commit now that switches /lib/rc/init.d to /run/openrc, and I am successfully running with it switched here. This makes /run mandatory for openrc. My question is, what you think we should do about the state data that still exists in /lib/rc/init.d after the upgrade, so I would rather not go there. Reading state data from both locations would add much code complexity for something that only exists until the next reboot, and the only time I could attempt to migrate would be if a tmpfs is already mounted on /run. Ideas are welcome, but I'm thinking that the best option is going to be to require a reboot.
(In reply to comment #4) > Reading state data from both locations would add much code complexity > for something that only exists until the next reboot, and the only time > I could attempt to migrate would be if a tmpfs is already mounted on > /run. Is adding a /run/openrc symlink to /lib/rc/init.d if /run is non-tmpfs a too ugly hack?
(In reply to comment #5) > (In reply to comment #4) > > Reading state data from both locations would add much code complexity > > for something that only exists until the next reboot, and the only time > > I could attempt to migrate would be if a tmpfs is already mounted on > > /run. > > Is adding a /run/openrc symlink to /lib/rc/init.d if /run is non-tmpfs a too > ugly hack? Thinking from upstream for a moment, /run may not exist, and in that case, openrc can't create it; it is up to the distro to make sure that it exists. It is true that I can (and probably will for now) have the openrc ebuild create /run, but for non-gentoo openrc users that doesn't solve the issue. Also, if we put a link in /run/openrc->/lib/rc/init.d, we have to add code when we boot that checks for and removes the link before we mount the tmpfs on /run. I would rather not leave an orphaned symlink in the /run directory.
(In reply to comment #6) > Thinking from upstream for a moment, /run may not exist, and in that case, > openrc can't create it; it is up to the distro to make sure that it exists. Can you really emerge openrc in that situation? There will be no mountpoint on boot for tmpfs /run. I thought that you intended to depend on the relevant baselayout version (does it exist yet?) if /run is mandatory. > Also, if we put a link in /run/openrc->/lib/rc/init.d, we have to add code > when we boot that checks for and removes the link before we mount the tmpfs > on /run. I would rather not leave an orphaned symlink in the /run directory. True, that's why I called it an ugly hack...
(In reply to comment #7) > (In reply to comment #6) > > Thinking from upstream for a moment, /run may not exist, and in that case, > > openrc can't create it; it is up to the distro to make sure that it exists. > > Can you really emerge openrc in that situation? There will be no mountpoint > on boot for tmpfs /run. I thought that you intended to depend on the > relevant baselayout version (does it exist yet?) if /run is mandatory. Eventually I will depend on a version of baselayout that makes /run, but it doesn't exist yet. So what I'll have to do is, make the /run directory in the OpenRC ebuild to make the directory. I'm already doing that in the udev ebuild for the same reason, and it is being done at least in the systemd ebuild as well. I don't know of any others. The bug requesting this in baselayout, for reference, is bug #361349.
This is fixed in commit 82d3918. Thanks for the report.
