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

Reply via email to