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…).