Re: ifupdown writes to /etc... a bug?
This one time, at band camp, Matthew Garrett wrote:
>Anthony Towns wrote:
>>On Fri, Mar 14, 2003 at 09:04:16PM +0000, Matthew Garrett wrote:
>>> Why is ensuring that /var/run [blahblahblah]
>>/var/run, being under /var, may be remote and only available later. We
>>want a name for something that cannot be remote and is available, rw,
>>early. The FHS doesn't specify such a name, therefore we must make one.
>/var/run is always available. It may not be the same /var/run, but
>that's an entirely separate issue. As long as it points to the same
>place, there's no problem.
>>Munging around with /var/run is unnecessarily complicated, buys us
>>_nothing_ but pain, and is probably impossible to do reliably. "/run"
>>is a solution that's easy to handle, easy to convert all existing systems
>>to, easy to describe, reliable, and easily adaptible for admins who want
>>to run their systems differently.
>/run is a solution that clutters up systems with yet another top level
>directory for no good reason. It introduces added complexity for all
>users in ensuring that /run is writeable at boot time, while with the
>current situation the vast majority of users have a writeable /var/run
>which would suffice. Why should all users have to deal with a problem
>that only affects a small number of corner cases, when the corner cases
>are probably going to have to be special cased anyway?
/run is a solution that doesn't require unneccessary symlinks.
/ and thus /run is writeable by default on Debian installations.
/var/run is not present very early on, because /var is on a *separate
partition* to /. There is no network involved.
mount writes to /etc/mtab for some unknown reason, it would now write to
/run/mtab. That's all.
How is this at all complicated?