hi, thank you for the response. please see inline... David Bustos wrote: > Quoth Andrew.Rutz at sun.com on Fri, Jun 08, 2007 at 02:32:58PM -0500: > >>1) where is the state-transitioning of a Milestone like >> >> svc:/milestone/devices:default >> >> actually *implemented* ? eg, could I dtrace it to >> watch the transition? > > [...] > > Since :true does not cause a separate process to be executed, I don't > think there is a good way to trace this in DTrace. The best I can think > of is to trace and decode the door calls between svc.startd and > svc.configd. > >
well, i followed my problem around, and it seems due to picld running before svc-syseventd. (i_ddi_io_initialize() returns FALSE, saying that syseventd isn't ready yet). to confirm, i looked at the /var/svc/log/* files, and it shows that picld starts one second before syseventd: (14:10:06 for picld and 14:10:07 for syseventd): ... [ Jun 8 13:24:39 Method "start" exited with status 0 ] [ Jun 11 14:10:06 Executing start method ("/usr/lib/picl/picld") ] [ Jun 11 14:10:07 Method "start" exited with status 0 ] ... [ Jun 8 13:24:39 Method "start" exited with status 0 ] [ Jun 11 14:10:07 Executing start method ("/lib/svc/method/svc-syseventd start") ] [ Jun 11 14:10:07 Method "start" exited with status 0 ] (my "smoking gun" was a debug version of the devinfo driver, which printed an err msg when i_ddi_io_initialized() returned FALSE) so, it seems i need to change picld's dependency. does this require an ARC case? also, what's the "spirit" of nominating a dependency? eg, fine-grain vs coarse-grain: eg, milestone/devices completes even later than syseventd, and (for a user/programmer) it probably is more semantically-intuitive to link picld w/ a device Milestone (as picld's job is to rummage around all the devs...) or... is it better to make a finer-grained dependency and link picld to syseventd because that literally is what it's dependent on? ...and if you answer "syseventd" ;-) ...then i'm back in the same boat, cuz syseventd forks and the parent returns ... and the child remains as a daemon... and the child doesn't announce that it can handle sysevents till essentially the last step in its init'ing. ...so there's a race between setting of sysevent_daemon_init global and the calling of i_ddi_io_initialized(). tnx /andrew