Renee Danson wrote: > On Fri, Mar 13, 2009 at 03:43:36PM -0400, Anurag S. Maskey wrote: > >> I have run across a race between nwamd and network/location setting >> location/selected property. >> >> 1. network/location and nwam are both disabled. >> 2. nwam is enabled. >> 3. nwamd enables network/location >> > > One thing I'm not clear on is why nwamd is enabling network/location. > I'm sure we must have talked about this and had a good reason for doing > so, but I can't remember it. In fact, it seems sub-optimal to have > services enabling and disabling other, dependent services. > There seems to have been a merge of two different designs. Looking back at emails and the specs, I see that we decided to have nwamd copy configuration files to a specific directory (/etc/svc/volatile/location_ready), and refresh network/location which would activate the location.
Rather than copying the configuration files, nwamd sets the location/selected property of network/location and refreshes network/location. When network/location is refreshed, the location is activated. During boot, network/location starts after filesystem/usr. By this time, nwam has already set the location/selected property and network/location can activate that location. There is, however, one change that needs to be done to nwam. When nwam is started, the Legacy location to be created. During boot, this is not possible because the filesystem is read-only. So, nwam will write the nwamcfg commands to create the Legacy location in /etc/svc/volatile/create_loc_legacy. When network/location starts (and also refreshes), it will do the actual creation of the Legacy location. Anurag > >> 4. nwamd sets/creates location/selected property to the appropriate >> location. >> 5. nwamd refreshes network/location >> >> What I've noticed is that sometimes network/location does not see the >> newly created/updated location/selected property. >> > > Any idea why this is the case? Fully understanding what's going on > will be useful in figuring out what the right solution is. > > >> Thus, it decides that >> the property doesn't exist and sets and activates the NoNet location. >> nwamd meanwhile is happily thinking that it has activated the right >> location (checking the active_loc variable). >> >> I can see two solutions to this: >> >> 1. rather than starting network/location right away, nwamd refreshes and >> (re)starts network/location only after checking the location conditions. >> >> 2. Rather than rely on active_loc, nwamd checks the location/selected >> property when the periodic conditions are checked. This way it know the >> actual location that's active. There's a delay before the correct >> location becomes active. >> >> I prefer the first solution as there's no lag and NoNet is not >> activated. What are folks' view on this? >> > > The second solution does seem like a workaround, rather than a solution. > The first might be reasonable; but I'd like to understand why nwamd is in > the business of starting network/location at all, and why the current > miscommunication is happening, before deciding that's the right approach. > > -renee >
