[OpenIndiana-discuss] How to document SMF facilities for an upstream package

[Rob McMahon]

On 03/02/2011 15:44, Gary Mills wrote:
> On Thu, Jan 27, 2011 at 10:04:52PM -0500, Gordon Ross wrote:
>> On Thu, Jan 27, 2011 at 7:45 PM, Gary Mills<mills at cc.umanitoba.ca>  wrote:
>>> I've just completed writing a spec file to build an IPS package for
>>> the ISC DHCP server.  I haven't made any changes to the source for
>>> this product, and don't want to.  That should all be done upstream.
>> Sometimes it's not that simple though. There's a lot of magic in SMF
>> (and even more in "ctfs" - contracts) so you can't necessarily just take
>> some open-source server program and run it as an SMF service.
>> As an example, I saw a problem with Samba where it did fork/exec of
>> some helper process (printing? I forget what) where that process died
>> with a fatal signal, and SMF took the whole service "offline".  The issue
>> here is that there are rules for running as an SMF service, which you
>> sometimes can't just ignore.  Something to watch out for.
> It must be an uncommon problem.  I've written many SMF manifests and
> method scripts without encountering that one.  They do need to be
> tested, of course.
It's not tough to fix.  From my amavis.xml:

<!--
     Children of amavisd sometimes dump core, shouldn't restart the entire
     service for this, amavisd looks after it.  amavisd-nanny will kill 
a child
     if it appears to be stuck.  It handles this too.
     -->
<property_group name='startd'
                 type='framework'>
<propval name='ignore_error'
                     type='astring' value='core,signal' />
</property_group>

Rob

-- 
E-Mail:	Rob.McMahon at warwick.ac.uk		PHONE:  +44 24 7652 3037
Rob McMahon, IT Services, Warwick University, Coventry, CV4 7AL, England