reassign 74312 ifupdown0.6
severity 74312 important
# ifupdown0.6 shouldn't make it to stable anyway; but *definitely*
# should not while this bug is open
thanks
debian-devel folks: The forthcoming ifupdown release (0.6) uses
a state file in /var/run to cope with different configuration (it
will automatically determine that you're at home, say, and setup eth0
differently to how it might if you were at work; when you tell it to
down an interface, it'll look up /var/run/ifupdown.state to see what
commands it needs to run to bring the interface down). Unfortunately,
the /var/run cleaning up done by sysvinit is done *after* networking is
initialised. This means, eg, that after a crash, ifupdown will be confused
about the state of networking because the old /v/r/ifud file will still
be about, and you'll probably end up with lo and eth0 unconfigured,
which would be bad.
On Sun, Oct 08, 2000 at 04:45:57PM +0200, Miquel van Smoorenburg wrote:
> According to Anthony Towns:
> > ifupdown 0.6 will use a state file called /var/run/ifupdown.state to
> > keep track of how the network's configured. This needs to be cleaned
> > up on the initial boot, but unfortunately S40networking is run before
> > S55bootmisc.sh.
> S55bootmisc.sh must be run after the network has been configured
> in case you mount /usr or /var from a remote server. I know this
> is not very common, but things have been ordered specifically to
> accomodate this. Consider S35mountall.sh, S40networking, S45mountnfs.sh.
Yeah, that's why I didn't just change S40networking to S60networking :)
Note that /var/run *is* the proper place ofr statefiles according to
the FHS, and that /var in its entirety is supposed to be machine specific.
The only clear alternative place to put it would be /etc, which will
at least be mounted by the kernel already if it's remote.
> So /var/run/ifupdown.state is a bad choice anyway if it is used
> before networking is configured. If ifupdown really wants to
> use it, it should clean it up itself somehow, but it would be
> better if it stored the info on the root filesystem somewhere.
Well, if we're going to insist (essentially) on /var/run being available
before networking's initialised, we might as well just change sysvinit. If
we're not then ifupdown has to be changed to look somewhere else.
> This is an awkward problem, and perhaps a new policy should be
> created to accomodate diskless systems - where to store state
> information before networking and remote fileystems are available.
Okay, well I think /var/run should be available before networking's setup
Embedded/diskless systems should be able to either just include /var/run
on their NFS mounted /, or setup a RAM disk.
> Anyway I don't think this is bootmisc's problem so I am
> reassigning it to ifupdown.
Reassigned to ifupdown0.6 since the 0.6 version is in a separate
package atm.
So, debian-devel people in particular, comments? Does just insisting
/var/run is available at boot seem workable/reasonable? Should ifupdown
just randomly insist on some other directory being safe to write statefiles
in at boot time before the network's configured? If so, which?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpV2MhYelgHl.pgp
Description: PGP signature