Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] /run directory and FHS

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: David Kowis <dkowis AT shlrm.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] /run directory and FHS
  • Date: Thu, 31 Mar 2011 10:02:33 -0500

On 03/31/2011 09:53 AM, flux wrote:
> 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. :)

I believe that the upstream implementations are going to use /run to
handle runtime information instead of /var/run as /run will be available
sooner in the boot process than /var/run will be.

>
>> 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.
>>
>> David
>
> 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.
> :)

Ah right, probably best to handle it via that. I was thinking that there
was an smgl-fhs boot script. It's too early to think about stuff.


David

Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.24.

Top of Page