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

Reply via email to