I thought you folks might be interested in something I put together a
while back.
I had to figure out a way to manage the handful of services that
comprise our application, in a way that would work on both Solaris and
Linux.
Ideally, of course, the scheme chosen would have several characteristics:
- Full SMF support on Solaris.
- Same user-visible CLI.
- Minimal duplicate functionality, especially for the services
themselves but also for things like the implementation of the CLI.
I started playing with reading SMF manifests, and pretty soon I was able
to read and mostly-parse all of the manifests I could find. Shortly
thereafter, I was able to do rudimentary start and stop sequences. From
there it was all downhill, until the point where I was able to start and
stop our application using an almost unmodified copy of our
administration CLI and almost unmodified copies of our service
manifests. We've been using it for several months now.
In its current state it's not really suitable for use as a whole-system
start/stop sequencer, but it's close. (The biggest issues: relocation
to a public directory, and enough error handling to survive the
occasional malformed manifest.) In addition, the CLI (although mostly
SMF-compatible) is not really intended for users yet; it's intended for
use by our administration tool. It lacks key UI features like "svcs".
All told, it's a bit over 4000 lines, mostly C.
Here's the brief internal writeup:
---
SMFlite: SMF on a starvation diet, for non-Solaris systems
Why?
- Common start/stop interfaces for multi-service applications, both for
application management software (e.g. "myapp start") and for application
components.
- Availability of SMF semantics on non-Solaris systems may help to
increase adoption of SMF.
What does it do?
- Reads SMF manifests.
- Starts processes in sequence in response to boot and enable.
- Respects enable/disable.
- Puts services into maintenance when their start methods fail.
- Stops services as required for disable and shutdown.
What CLIs are supported?
svcadm enable -r fmri ...
Partial support for -t.
-s is assumed.
svcadm disable fmri ...
Partial support for -t.
-s is assumed.
svcadm clear fmri ...
svcprop -p group/name fmri
one property, one fmri
What's different?
svcadm boot
Starts all services that are enabled.
svcadm shutdown
Stops all services, whether or not enabled.
(Hmm. Maybe this could work by disabling a "none"
pseudo-service on which all services depend.)
What's missing in SMFlite?
Well, aside from Everything:
- health monitoring/automatic restart (may be impossible without contracts)
- % tokens in exec methods
- Config repository (but getting closer)
- most of the CLI (svcadm restart, refresh, mark, milestone, ...)
- status reporting (very limited, through svcprop -p restarter/state)
- timeouts
- enable/disable -t don't work right
- some dependency subtleties (e.g. any vs all)
- milestones
- Isolation (services are a descendant of the invoker, rather than startd)
- Only handles svc.startd-style services.
What SMFlite is never going to have:
- Contracts (uses process groups). If anybody ever adds them to the
Linux kernel, it would be better to port real SMF.
General comments:
- Error handling is *very* rudimentary. If anything serious goes wrong,
it just stops. (It can handle service start/stop failures, but not XML
errors.)
