Jesse Keating wrote: > On Wed, 2009-01-21 at 07:58 -0800, Jesse Keating wrote: >> This patch now uses the existing isys call to reset the resolver. >> >> I really have to start using -i with grep :/ > > I'm still not entirely happy with this, as I think there is a race > condition here. NM kicks things off as soon as the ifcfg-* file is > written out, which is done as part of self.write() in network.py. Just > after the ifcfg file is written, we try to construct the hosts file, > which relies on a working resolver. We don't actually block on the > network being up before we do the lookups. > > I think what we really need to do here is split out the writing of the > ifcfg-* file from the rest of the files, and wait until network is up > before writing out the rest of the files. (actually writing out the > rest isn't really necessary during early network bring up I think, that > whole part can be delayed until the pre-install call where we write them > to the install filesystem). > > David, what do you think? We still need the call to reset the resolver simply because of how name resolution works in glibc. We could follow suit with NM and use libgio2 from glib2 to monitor resolv.conf and hosts and reset when those change. I don't really want to split out the writing of the config files from where they are, we just need to listen to NM more closely and wait for things to finish on its end. We've already got code to check the overall status of the network connection. That combined with some libgio2 usage and sanity checking of those files (maybe) could let us always have the resolver reset once everything is in place. -- David Cantrell <dcantrell@xxxxxxxxxx> Red Hat / Honolulu, HI _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
