> I did the step...and I completely agree. Simple things are hard with
> SMF !
> We need a easier way to create "stupid" services.
> Count how many things you have to do for a simple "/usr/local/sbin/
> mydaemon -D".
I'm not an SMF expert, but let me take a crack at that. I'm assuming
that "mydaemon -D" straightforwardly runs until killed...
---
<service_bundle type='manifest' name='mydaemon'>
<service
name='application/mydaemon'
type='service'
version='1'>
<instance name='default' enabled='true'/>
<exec_method
type='method'
name='start'
exec='/usr/local/sbin/mydaemon -D & exit 0'
timeout_seconds='60' />
<exec_method
type='method'
name='stop'
exec=':kill'
timeout_seconds='60' />
</service>
</service_bundle>
---
Take that and put it in /var/svc/manifest/application/mydaemon.xml.
If you're delivering it in a package, make its class be "manifest" and
you're done.
If you're just copying it into place, feed it to svccfg import.
I haven't tested that, and so I might have missed a detail or two - in
particular, I'm not sure that shell syntax is acceptable in a method
invocation, so it might be necessary to interpose a 3-line shell script
- but I don't think it's a lot more complicated than that.
That seems to compare pretty favorably to a "traditional" mechanism.
Not that a traditional start script is all that hard, but a traditional
kill script is harder, since you have to track a pid (and are you sure
that pid still belongs to your daemon?) or hunt down instances of your
daemon with pgrep (and are you sure there aren't any false matches?).
Of course, this is a very minimal service, but that's what you asked
for. If you want to express dependencies, it's a little more
complicated (but then in a traditional configuration we'd have to talk
about where to put the script in the S* and K* sequences). If you want
to include configuration information, that too is more work, but so it
would be in a traditional configuration. If you want to properly track
whether the service came up, that's a bit harder... but again, it'd be
harder in a traditional environment, and here there's a clear mechanism
for reporting and handling the failure.
Yes, it's very _different_ from the traditional mechanism, but in an
absolute sense is it _harder_?
Note that even in this minimal example, you get significant gains over a
traditional installation:
- Your service is visible in service lists.
- Its output is logged in an organized way.
- The administrator can enable and disable it.
- If the administrator manually enables it, it gets the standard
environment, not the administrator's personal environment.
- There's zero risk of hitting the wrong program when you kill it.
- It starts in parallel with other services, for better boot performance.
- It's automatically restarted if it dies.
(Note to SMF core team: This could be a bit simpler still. Have
defaults for more of the attributes. The default for the "type"
attribute on <service> could be "service". The default for the "type"
attribute on exec_method could be "method". I wonder whether the
various types of service_bundle would be better done as different
element names, eliminating the "type" attribute. Can there be a default
for timeout_seconds? Perhaps the stop method could default to :kill.)
