Re: ifupdown writes to /etc... a bug?
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.
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.
> 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.
MfG
Goswin
Reply to: