Todd Pisek wrote:
Nicolas Williams wrote:
On Fri, Jun 05, 2009 at 03:40:17PM -0500, Todd Pisek wrote:
I have a service that is associated with the disable_fmri actuator.
Is there a way for the disable_fmri service's stop method to return
failed status back to IPS such that IPS aborts the remove?
If IPS is acting on a image that is not booted, then the disable won't
take effect until later, and, really, the stop method probably won't run
at all (since you're probably removing the service too). Even if the
image is running, the service might not be.
When the image is running the only thing IPS could know is whether the
service transitioned to maintenance, [likely] as a result of disabling
it. That's not really a lot of info to go on.
So, IMO, IPS should not act on the result of disabling any service.
(For that matter, the same applies to enabling and refreshing any
service too.)
Nico
The way I interpreted pkg(5), was that disable_fmri would run 'svcadm
disable <disable_fmri>' before removing files. I assumed the purpose of
this was to make sure the package's daemons etc. were stopped before
removing files and IPS would not remove anything until the service
disable completed. Is this correct?
It actually runs svcadm disable -s fmri; since it's synchronous
svcadm should exit w/ a error code if the stop method fails, which
will stop the packaging operation. However, we have no situational
context, so we cannot deliver a solution-oriented error message.
In general, relying on the packaging system to interlock w/ system
services to perform required shutdowns, etc, is sketchy. We don't
interlock /usr/bin/rm, either. It will mostly work, but uninstalling
packages that are in active use is a bad idea.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
