Re: ifupdown writes to /etc... a bug?
This one time, at band camp, Goswin Brederlow wrote:
>Jamie Wilkinson <jaq@debian.org> writes:
>
>> So, I propose the following course of action:
>>
>> 1) Create /run in base-files, mode 755, owned by root.root.
>
>It was suggested to use /mem and thats whats used in my patches.
>So far it doesn't have to exist but if it does its supported.
>That makes transition easier I think.
It was also suggested to use /run instead of /mem for various reasons,
including that /mem has a misleading name if it's not actually in
memory.
Not that I don't appreciate your work, I think it's great that you've
already patched mount to have saner behaviour.
Anyway, I think that /run is a much better name, given that it already has a
sister directory /var/run with the same purpose (but as explained earlier
may not be available to mount)
>I also suggest using /mem/state or /run/state so one can just use the
>/var filesystem for /mem too.
>
>> 2) Patch those programs using /etc to store state to check for the existence
>> of first /var/run and then /run, and use the first found location as the
>> location of their state files. Thus we can use /var/run if (e.g. on a
>> workstation) /var has been mounted, and /run if it has not.
>
>What then if later the program is run again, then /var/run exists but
>with a file from the last boot? Software could realy get confused if
>the time /var is mounted is ever changed (e.g. when moving /var from /
>to its own fs).
>
>/var is already recomended policy and fsh already says to use it. Only
>a few essential programs should be allowed to break that and use
>/etc/foo (possibly linked to /run/foo in which case they need to use
>/run/ for temp files too). Those few exceptions should be explicitly
>named and they should allways follow their own exception.
>
>I'm against moving files from /etc/ to /run or /mem or whatever for
>historical reasons. Too many people are used to /etc/mtab or
>/etc/resolv.conf and too much software breaks thats prefectly fine
>with a symlink already. 4 or 5 links in /etc won't hurt.
Most programs won't need /run, /var/run should already be available. I'm
thinking for the specific case of mount which is in the process of mounting
/var, it'll need /run/mtab.
So, programs will know where their state files are, and use that one
location for the entire lifetime of the system. If they started using /run,
then they'll keep using /run; if they started using /var/run, then
they'll continue to do so. If a program has problems reading an old version
of its own state file, then it's got bigger problems that are outside the
scope of this problem.
I thought it was already explained that we'd knowingly be breaking FHS by
providing /run, and that we'd spell out its usage in our own policy, so It
Is Okay(tm) to use /run for mount's mtab. We wouldn't make exceptions for
programs writing state to /etc, because we've defined better places for them
to write to.
Why are you against moving files? We can provide a symlink from /etc/mtab
to /run/mtab to smooth the transition just as we did with /usr/doc.
I feel like I'm saying the same stuff over and over again. If I am not
being clear on anything, please say so.
>> 3) Amend policy to acknowledge /run and specify that programs requiring a
>> location to write state to when the system is still being initialised
>> (i.e just after the system has booted, prior to /var being mounted) use
>> /run; for all other programs the FHS applies.
>
>Explicitly name the programs allowed to not use /run instead of /var
>and make /var mandatory for machine writeable files.
Sure, eventually the policy will require programs to not write state to
/etc, once the infrastructure is there to allow programs to behave
correctly, and bugs can be filed.
As soon as I feel there's sufficient support for my plan, I'll do the work
to get it moving, but right now I'm still waiting for more comments from my
learned colleagues (i.e. waiting for someone to flame me :-)
--
jaq@debian.org http://people.debian.org/~jaq
Reply to: