On Thu, Sep 03, 2009 at 03:58:18PM -0700, Danek Duvall wrote:
> Rishi Srivatsavai wrote:
> > (2) Create a new SMF service that runs late in boot and also only once
> > on boot after upgrade to perform the PVID update. Please share any pointers
> > to existing SMF services that are similar and run just once.
> 
> This might work, but I don't know much about services disabling themselves.
> I would presume it's safe to run "svcadm disable $SMF_FMRI" from within the
> script, but folks on greenline-discuss would know better.

I've posted a script before that services can use to delete themselves.
The same logic allows for disabling too.  The same logic allows for
removal of the service and pkg that delivered it both.

Briefly: the service delete/disable tool runs itself again via ctrun(1)
so as to leave the process contract of the service in whose context it
was running, then waits for the service to transition to online (or
maintenance, or degraded) and then disables/deletes the service.  If
this tool is not in /usr/sbin then it should create a temp copy of
itself in $TMPDIR and execute that version via ctrun.

> The question I see with this is whether this will ever need to be run
> again.  You have to keep delivering the service as long as you care about
> transitioning people across this flag day (just like you would have to
> carry the code in your postinstall script or upgrade script for that long),
> but if you never have to run it again, then it can stay disabled and not
> worried about until it's time for the service to be removed.

> However, if it does need to be run again, I'm not sure how you'd go about
> re-enabling it.  There might be some mechanism with enhanced profiles that
> would let you do that, but I don't think so.

Can't the IPS SMF actuator have an option to enable disabled to-be-
pinged services?  (I realize that most of the time one would want the
actuator to honor disabled services.)

Nico
-- 
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to