smf(5): the system knowing more means...

you can choose to know less. For instance, if you need to know what application model your program runs under, then you have to know how to start or restart or stop your application. The common example is that, if you run a process under inetd(1M), then telling inetd(1M) to take notice of your new service (or your newly deactivated service) requires knowing that

# pkill -HUP -x inetd

will cause inetd(1M) to rescan inetd.conf(4), its configuration file.

But for a service started by init(1M) out of inittab(4), you edit that configuration file and then

# init Q

And for a service that is started somewhere in /etc/rc*.d, restarting looks something like

# /etc/init.d/foo restart
Usage: /etc/init.d/foo {start|stop}
# /etc/init.d/foo stop
# /etc/init.d/foo start

and making this service start on boot consists of creating a link to the /etc/init.d file to some sequence number in the appropriate run level directory. (I'll omit discussion of saf(1M), but that's another distinct method for managing services.)

All of this, of course, could be simpler.

If the service describes what other service is responsible for starting it and stopping it (and restarting it or asking for its configuration to be refreshed), then a single command can relay the appropriate instructions to the responsible restarter. In smf(5), this command is svcadm(1M). Our examples above all reduce to

# svcadm restart application/foo

or to

# svcadm enable application/foo

depending on whether you wanted to restart or merely enable (and start) the service in question.

Of course, since we also know what other services application/foo requires, we can actually enable all required services automatically, by following our service graph. Let's make this more concrete: to enable the SSH daemon on Solaris, all you need to do is:

# svcadm enable -r network/ssh
# svcs -p network/ssh
STATE          STIME    FMRI
online         Sep_14   svc:/network/ssh:default
               Sep_14     100152 sshd

What's svcadm(1M) doing? We can ask it for verbose output:

# svcadm -v enable -r network/ssh
svc:/network/ssh enabled.
svc:/system/cryptosvc enabled.
svc:/system/filesystem/minimal:default enabled.
svc:/system/device/local enabled.
svc:/system/filesystem/usr enabled.
svc:/system/filesystem/root enabled.
svc:/network/loopback enabled.
svc:/system/filesystem/usr:default enabled.

svcadm(1M)'s output represents its traversal of the dependencies for sshd(1M). Taken across the many services included in Solaris, that's a lot of knowledge we've formalized and moved into the system. It becomes the basis for a lot of "meta-service" administration, including automated restart.

If you didn't know these dependencies already, you can interrogate the system (using svcs(1)) and cement your understanding; if you did, then you can answer the second-order questions like, "what is affected by a failure of system/utmp?" much more rapidly than in the past. Or you can instead know less and devote your newly freed neural capacity to understanding your application stack as a whole (or to maintaining encylopedic knowledge of Simpsons trivia...).