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?
SMF does not treat milestone/devices specially. As with all services, its state is dictated by its restarter. milestone/devices' restarter is svc.startd, and since the service requests "transient" behavior (via the "general/startd_duration" property), svc.startd will set its state according to the outcome of its methods. Since milestone/devices' start method is ":true", the service will be marked online as soon as its dependencies are met. 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. > relatedly, i'm inferring the semantics of this > Milestone by using "svcs -d ..." to look at what it's > dependent on. is there another place that describes > the "spirit" of this Milestone? eg, the "single-user" > Milestone maps onto one of the run-levels. It doesn't refer to any documentation, so you'd have to consult the ARC case which introduced it. Which is apparently the original SMF case. Which describes "milestone/devices/system" as "All system devices established. See /etc/rcS.d/README." > 2) for a binary like devfsadm, which can self-daemonize, > how does a Dependency actually work ? eg, the Service > system/picl relies upon devfsadm via this Service: > > svc:/system/device/local:default > > even if there's a "require_all" attribute, if devfsadm > daemonizes, how can picld compute whether devfsadm > is really "done" doing its activities? A service's start method should not return until the service is ready to service requests. If the service is implemented by background processes, then the start method should wait until the background processes have communicated their readiness before returning. If device/local's start method returns before devfsadm is ready, then that is a bug in the device/local service. > 3) i see in /var/svc/log/* there's a log per Service, but > these are logs w/ "Service-level" info (eg, "restart > was called", etc. is there some other log that is > the union of all the Services' run-time output ? ...or > is that still /var/adm/messages (or whatever's setup > in /etc/syslog.conf ? svc.startd executes start methods with their standard output file descrptor redirected to the /var/svc/log file. If a service logs to standard output, then that output should be captured to a log file. If a service chooses to log elsewhere, then the information will be elsewhere. I'm not sure if there's an overarching strategy for new services. David