Hmmm, how does svc.startd recover FMRI status when it dies and is restarted?
Clearly the contract decoration case will help! For each adopted contract on restart svc.startd can match the ctid to FMRI. But what about service state? The existence of a non-empty process contract for some non-transient FMRI does not imply "online," nor does the existence of a non-empty process contract for some transient FMRI imply "start method running." Perhaps there should be a way to decorate process contracts with service state (starting, online, degraded, stopping). To simplify recovery and/or cancellation of method_threads in svc.startd it'd be even better if we could rely on start/stop methods and/or the services themselves to maintain this state property of process contracts. But we probably can't make that assumption. We can't assume monitor methods yet either. So when svc.startd recovers, even if there was a state decoration on every contract, it will not be able to always fully recover state (e.g., if svc.startd died while some start method was running but had not yet exited). Or did I miss something about how svc.startd recorvers state? Nico
