David Bustos wrote:
> Quoth Andrew.Rutz at sun.com on Fri, Jun 15, 2007 at 02:45:57PM -0500:
>
>> I modified syseventd's 'start' method to have a "sleep 30" (so that
>>I could investigate a race condition).
>>
>> I then see this in syseventd's log:
>>
>>[ Jun 15 14:30:36 Executing start method ("/lib/svc/method/svc-syseventd
>>start") ]
>>[ Jun 15 14:30:37 Method "start" exited with status 0 ]
>>[ Jun 15 14:37:55 Method "start" exited with status 0 ]
>>
>>syseventd fork()s and leaves a daemon running. are the parent and
>>child processes BOTH saying they completed the 'start' method ? eg,
>>is there a libscf func being used at runtime to declare that 'start'
>>is complete? (eg, syseventd's binary links libscf:
>
>
> For contract services like syseventd, "start" is judged to be complete
> when the start method exits successfully. I can't think of a reason why
> you would see two start exits in a row without an intervening start
> start, unless perhaps you rebooted inbetween. File a bug, and include
> the output of "echo ::startd_log | mdb -p `pgrep startd`" just after the
> second start is invoked.
>
>
> David
i'm also seeing another race when i add a "sleep(10)" in syseventd's
child-proc code (right before it enters its FOREVER) loop.
i've got system/sysevent as system/picl's Dependency, but w/ this
SLEEP in the Child code, the Parent sysevent code is exiting and
seemingly satisfying smf's requirements... but this seems to be
the type of bug you've referred to: syseventd is announcing that
it's ready to provide a Service... yet its child-proc hasn't
completed (and set a global that's returned by i_ddi_io_initialized()
...and used for inter-process synchronization).
(Note that milestone/single-user and fmd are dependent on sysevent,
so this is important to "get right". I tried to file a bug on
this, but bugster was hiccupping)
/andrew
ps - 'seems like a cool tool would be a static-analysis tool (like
warlock) that would check the src code for violations of Dependencies
(that are computable statically). eg, in my case, any code calling
i_ddi_io_initialized() would have to AT LEAST have system/sysevent
as its Dependency (as syseventd sets the global that that func
returns). (eg, system/picl was erroneously dependent on
milestone:/filesys/minimal... even though cscope shows that picld calls
i_ddi_io_initialized(); it was only a matter of time/cases before
failure would occur).
all Dependencies could not be computed at compile-time, but it would
find the easy cases... 'whether in new code or modified code.
