Sebastien Roy wrote: > Cathy Zhou wrote: >> It might because that I didn't add linkmgmtd as a dependency of the >> network/nwam service, which I should. > > The nwam service is an instance of network/physical, so the dependency > is there. > > bash-3.00# svcs -l nwam > fmri svc:/network/physical:nwam > name physical network interface autoconfiguration > enabled true > state online > next_state none > state_time Wed Apr 25 23:25:07 2007 > alt_logfile /etc/svc/volatile/network-physical:nwam.log > restarter svc:/system/svc/restarter:default > contract_id 9 > dependency require_all/none svc:/network/loopback (online) > dependency require_all/restart svc:/network/linkmgmtd (online) > > I think it's something else. >
I agree it's something else, but I think we still have a race condition here. linkmgmtd does all of its SMF and door call initialization after it daemonizes. When linkmgmtd daemonizes, it returns and the SMF start script for the linkmgmt service continues. SMF could then start nwamd before linkmgmtd has finished its initialization. Again, I don't think this occurs because nwamd relies on ifconfig to plumb interfaces. On Seb's machine the interfaces were plumbed, which requires an upcall from dls to linkmgmtd, so I believe linkmgmtd finished its initialization before nwamd tried to plumb the interfaces. We'll need some mechanism to make sure linkmgmtd is finished its initialization before SMF tries to start other things. I wonder if we could use the door file for this? Initializing the door is the last thing linkmgmtd does when it initializes. Say have the start up script delete the door file, then linkmgmtd will recreate the door file when it initializes the door, and once the door file exists, the start script can terminate. We can have the start script give up after a while if the door file never shows up (to keep from hanging on boot). thoughts? thanks, Dan
