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


Hi Stephen, smf looks like great stuff! I never realized how much UNIX trivia was needed to track down services and dependencies. I think smf will really help with security and service availability. Thanks for the examples, I can't wait until smf is released into Solaris Express.

Posted by William Hathaway on September 20, 2004 at 01:39 PM PDT #

@William: Thanks! (Yes, there's a lot to know if you're really trying to know \*everything\* that's going on.) And we'll keep the examples coming, along with an "opinion" paragraph every now and again. - Stephen

Posted by Stephen Hahn on September 20, 2004 at 02:27 PM PDT #

Hi Stephen, I managed to get a look at some systems running build 68, obviously with SMF running. Startup time seems well improved on these, good to see. Tadpole specialises in notebooks running Solaris and have for some time now had a fairly simple tool to enable users to control services on per location basis. This all revolves around the network interfaces and available conectivity. The SPARC notebooks can do CPR so we want to be able to change all this without rebooting! In the past this has been based on running the system with just the loopback interface running and enabling/disabling the physical interfaces as needed. Any services dependant on the physical interfaces need to be stopped before interfaces are reconfigured and then restarted. Obviously the new smf requires that the tool be updated. But looking through the documentation I came to realize that it could help. I could envisage a service bundle for each location that svc.startd could actually manage although I'm still not clear how you would create such a thing. The other missing link seems to be that disabling a physical network doesn't actually do anything on the running system, i.e. it doesn't ifconfig down the interface. Are there any plans to go that one step further? Great addition in any place.

Posted by Andy Giles on October 15, 2004 at 12:49 AM PDT #

@Andy: Good questions. (And sorry I missed your comment.) The plan for the network interfaces is to become much more flexible about scenarios like the one you describe. The current networking service sequence, taken in its totality, is probably not symmetric with respect to setup and teardown. I'd be happy to experiment with customizing for the laptop scenario (no tunnels, no VPNs, etc.) with you. — Stephen

Posted by Stephen on October 31, 2004 at 06:01 AM PST #

Post a Comment:
Comments are closed for this entry.



« April 2014
External blogs