[SM-Discuss] /run directory and FHS
flux at sourcemage.org
Thu Mar 31 10:53:38 EDT 2011
David Kowis (dkowis at shlrm.org) wrote [11.03.31 23:25]:
> Cannot do the symlink thing (from the article):
> "/var/run otoh is only available very late at boot, since /var might
> reside on a separate file system."
This does not preclude having the reverse symlink though (i.e., symlink
/var/run to /run). You mention bind mounting further down; I'm just
clarifying that symlinking is also still an option (as is having two
actual separate directories, but I don't see the point of that since
they serve the same purpose).
> Also this is of note:
> "Dracut, udev and systemd have already been updated upstream to make use
> of /run. We expect mdadm and mount to follow suit quickly."
I understand mdadm, but what does mount have to do with this? Are they
implying that it will be hardcoded into mount, so that even without
having it in fstab doing mount /run will "just work"? Aside from that I
don't see how this affects mount at all. I must be missing something. :)
> Probably best to stick it into smgl-fhs and get it set up as soon as
> possible for multiple things to use it. We can bind mount /var/run to
> /run at a later date, so that's still acceptable, just in the other
> direction. As well as binding /var/lock to /run/lock.
I would still argue that creating the directory (or at least testing for
its existence and creating it if it's missing) via init scripts is the
most robust way to get it onto a system. Typically smgl-fhs is only
ever cast once (not counting cleanse runs), and if such a critical
directory somehow got wiped out the whole system would be dead in the
water. Having a means to ensure that its there every boot is a good
idea, IMHO. Also, it is meant to only ever hold a tmpfs, so I think it's
OK to create it on boot. Of course it's also OK to create it via
smgl-fhs, but at let's put some tests in the boot scripts to make sure.
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 490 bytes
Desc: not available
Url : http://lists.ibiblio.org/pipermail/sm-discuss/attachments/20110331/ab732935/attachment.bin
More information about the SM-Discuss