[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: