Jesse Keating wrote: > On Wed, 2009-01-21 at 07:59 -1000, David Cantrell wrote: >> >> 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. > > We were already calling the resolver reset, essentially in one location, > which was after we've monitored for NM to bring up the connection. > Unfortunately, within the call to bring up the NM connection, we call > network.write() which is where the trouble is. We use write() to tell > NM to bring up the connection, but within write, we're depending on > having a working connection. Correct, but that's more or less how we are feeding config data to NM for the moment. Inside write(), where we depend on the network, we should be waiting for NM rather than waiting in the one location. I prefer the single write() function in the network.py file for simplicity. All network information gets dumped out from there. -- 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
