[crux-devel] TODO28: /run

[Michal Soltys]

W dniu 04.04.2011 11:10, Moritz Wilhelmy pisze:
> Dear CRUXers,
> 
> TODO28 in the wiki mentions the possible inclusion of /run in the next release.
> While I see the point of this for other distributions, I'm not completely
> convinced we should do so as well.
> I didn't want to break this discussion from the fence in the wiki (because a
> wiki is not the place to discuss that kind of things), and I didn't notice any
> discussion at all on the matter, so I decided to post here.
> 
> Here my few points:
> 
> * /run is not yet in FHS.

Well - /usr/share/man is in FHS, but Crux goes on with /usr/man pretty fine.
FHS also prefers /lib64 over /lib, regardless if we're on pure amd64 system
or not. Point being - I've always seen FHS more like a set of suggestions,
than something that would have to be followed to the letter. Note, pretty old
suggestions.

> * Early boot should start udev, and then /var will be mounted. We don't use
>    systemd, and creating /run just for udev seems out of place. I don't mind if
>    udev creates it's directories in /dev/.udev, because udev is halfway related
>    to /dev anyway. I see the point on distros using systemd, since they need to
>    cram other, unrelated stuff into /dev, so /run is probably a better design
>    choice for them; Nevertheless, CRUX is not fedora. So unless anyone wants to
>    switch from SysV-init to systemd for the next release, I vote against /run.
> 

It's not only about systemd.

Whole point was to standarize the way of transferring data from
initramfs to the real [file]system. As /dev is usually mount --move'd (along with
/sys and /proc) before chrooting - it became kinda "natural" to keep runtime data
there, that should be handed over (as a bonus /dev is also persistent with
devtmpfs). For example - mdadm keeps/ed its stuff there during incremental
assembly.

So to clean things up:

The first option was to simply use /dev/.run tmpfs and mount --move that
subdirectory to /var/run . But that was a bit ugly as well - e.g. init scripts
would have to make sure /var is not overmounted (so: mount --move "away",
mount /var, mount --move /var/run "back in place").

So to not complicate things, they settled for a clean and simple method:
/run tmpfs, --mount move to /run on real filesystem before chroot. KISS
and no problems with accidental overmounting. As a bonus /dev is
finally only for the device related stuff (not even .udev there anymore).

The adopting is completely (I think) neutral:

- tmpfs mount over /run (possibly with some reasonable limits) - 
  if it's not already a mountpoint (similary like udev checks if /dev is
  an exisiting mountpoint, eventually remount to enforce limits).
- symlink /var/run -> /run and /var/lock -> /run/lock

Few trivial patches could do the thing at any moment, without causing any
compatibility problems (I don't think anything freaks out if /var/run is
a symlink) or surprising less technical people.