I've been doing a LOT of research on SMF and created several manifests and am
very happy with how all the pieces work and the additional functionality that
is now available. The one question that I have been unable to find an answer
to is the reason for this post.
Before I list my question please understand that I have seen a lot of posts
from people asking why you would want to do this, or stating how stupid the
idea/concept is so please try to keep an open mind. The service I am using is
not the intended service that I want the behavior for it is just a good service
for testing the behavior without corrupting data.
Basically I have a network service (stunnel) that I want to:
1. start at boot time.
2. Not try to restart if the process dies (IE: pkill -9 stunnel)
3. Change the status from online to something else (IE: maintenance)
Part 1 is not a problem.
Part 2 is doable if I use:
<property_group name='startd' type='framework'>
<propval name='duration' type='astring' value='transient' />
</property_group>
Part 3 is the tricky part. ( At least for me )
I saw a post
(http://www.opensolaris.org/jive/thread.jspa?messageID=114094𛶮) where
they wanted the same behavior for xntpd and the fix was to write C+ code. That
post was back in 2005 and I'm hoping that there is either a better way to do it
now or that it is at least being looked at as an option to add to the SMF
framework.
With RC scripts the service will die and not try to restart itself but there is
also nothing that reports the service as being "online." With SMF I don't want
the service to report that it is online when it is not.
If this has been discussed somewhere else I apologize for the repeated post but
I have done a lot of searching and have not been able to find a clear cut
answer to this problem. I hope that I'm not the only Solaris Admin in the
world that wants to do this but if I am please tell me what other options I
have. (Other than sticking with RC Scripts).
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
