Hi Harry,
It's not actually that difficult once you get used to it. Think of it
like learning a new programming language - you're not going to write an
entire OS from scratch on your first day. Here's an example that took
about 30 mins to write (although the bulk of this was looking into the
restart_on property for the <dependent> tag):
<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM
"/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type='manifest' name='myservice'>
<service
name='application/myservice'
type='service'
version='1'>
<create_default_instance enabled='true' />
<single_instance/>
<dependency
name='fs-local'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/system/filesystem/local' />
</dependency>
<dependent
name='myservice_system-log'
grouping='optional_all'
restart_on='error'>
<service_fmri value='svc:/system/system-log' />
</dependent>
<exec_method
type='method'
name='start'
exec='/lib/svc/method/svc-myservice'
timeout_seconds='60' />
<exec_method
type='method'
name='stop'
exec=':kill'
timeout_seconds='60' />
</service>
</service_bundle>
/lib/svc/method/svc-myservice could contain:
#!/bin/sh
. /lib/svc/share/smf_include.sh
FIFO=/tmp/myfifo
# Something here to grep $FIFO /etc/syslog.conf and add it if not there
[ ! -p $FIFO ] && mkfifo -m 644 $FIFO
/usr/local/bin/pipe_reader.pl $FIFO &
exit $SMF_EXIT_OK
You could even use a property within the SMF service (defined in the
manifest) to store the location of the fifo, but we're getting more
advanced there... It does avoid having to modify the script each time
you want to change the fifo location.
Do bear in mind that the SMF framework is much more than simply a "if
not running, start" type of monitor for services. It allows interlinking
with dependencies, multiple instances of the same service, grouping of
faults into boundaries (the "contract" subsystem), running in "degraded"
mode (although I've not seen this used yet), handling of multiple zones,
etc...
One of the most useful places I've interacted with SMF is the rpcbind
program. If rpcbind dies and is restarted on Solaris 8/9, then all your
services stop working unless you restart each by hand. With Solaris 10+
and SMF, if rpcbind dies, SMF will restart it. Moreover, it will also
restart any services which have declared a dependency upon rpc/bind and
with a restart_on property which is != 'none'.
The example manifest above will actually restart system-log (i.e.
syslogd in the current zone) if "myservice" dies. Also, the
"optional_all" dependency in the "dependent" section states that
system-log will not be prevented from running if myservice is disabled.
i.e. syslog won't break if you disable myservice.
All in all, very useful for automated restarting of a service *and its
dependents*.
Hope that helps,
Brian
Harry Putnam wrote:
Brian Ruthven - Solaris Network Sustaining - Sun UK
<[email protected]> writes:
Hi Harry,
I've got nothing canned which I can quickly pass on, however, anything
I gather will be from google ;-)
The top three hits searching for "writing smf manifest" look useful:
http://www.sun.com/bigadmin/content/selfheal/sdev_intro.jsp
http://wikis.sun.com/display/BigAdmin/SMF+Short+Cuts
http://blogs.warwick.ac.uk/chrismay/entry/solaris_smf_manifest/
[...]
Jesus... after looking at those URL a bit I feel like just start
boohooing and go home. This SMF stuff seems horribly complicated to
me. They use terms like `JBoss' with no explanation..
And the XML itself just seem vastly overdone for something that should
be fairly simple.
Hopefully that is enough to get you started. I'd suggest copying the
manifest from a simple service such as utmp.xml and customise it to
your needs. If your service needs a startup script, then you should
include /lib/svc/share/smf_include.sh so you can use the correct exit
codes to signal the right things to the framework.
I guess it will be a start... but man I don't understand hardly any of
it.
To attach a script to an existing service and make it restart when
that service restarts is not really something that should require
yards and yards of code, several documents, and god only knows what
else.
Its tempting to just write a perl script, that looks for the service
to be running, and starts up if it is.
Is that a really bad approach for this?
`this' in case it has gotten away in the thread is to run a script
that reads from a named-pipe.. that the syslogger writes everything
to.
The purpose of the script is to have finely grained control over
writing various things to logs... using regular expressions.
And after starting on the script, I realized I might want to change
the regular expressions as the script runs.
So far, I've figured out a way to do that I think, by making the
script read a secondary file every five minutes. I might write a
regular expression and matching log file in the secondary file and
the script as it runs will start looking for those. And writing hits
to the new log.
So far I plan just to use matching pairs in the secondary file like
this.
REGEX LOG.log
What I haven't really got into yet is the best way to have this script
running in the background... checking for syslog to be running. That
is, the script would never stop running even if the syslogger shut
down.
Maybe even some kind of `trap' in the script where it would send me a
message in the event it was killed. (At least for some kinds of KILL)
That's where it starts to look like it might be better to insinuate
this script in there through SMF.
I'd really like to see a simplified example of how that might be
done. Maybe there is an example like that in the URLS you posted. I
haven't gotten very far looking into them.
_______________________________________________
opensolaris-discuss mailing list
[email protected]
--
Brian Ruthven
Solaris Revenue Product Engineering
Sun Microsystems UK
Sparc House, Guillemont Park, Camberley, GU17 9QG
_______________________________________________
opensolaris-discuss mailing list
[email protected]
