So you want to be able to interrupt any boot to any milestone, and instead do
the patch processing if a patch is pending. You basically want to interrupt
the current milestone, and instead just boot to filesystem-local and do the
patching.
The question is, can the smf milestone be changed mid-milestone?
My test shows that it can. How about:
1. Create patch-test-service, on which single-user depends. This will
"svcadm milestone patch-install-milestone" if a patch needs to be
installed. This service is always enabled.
2. Create patch-install-milestone, which depends on patch-install-service
below.
3. Create patch-install service, which depends on:
single-user
filesystem-local
This service is always enabled. It will install a patch if it is pending,
otherwise, do nothing. If the service fails, it might need to:
# svcadm milestone single-user
So that a maintenance prompt will be appear on the console. This might
not be necessary. you might get this anyway, as console-login is not
reached.
It should be ok to issue smf commands from an smf service, as long as they
do not try to do any synchronous operations (-s).
This approach is also good because an explicit boot to single user WILL NOT
attempt to install pending patches.
Disabling the patch-test and patch-install services will disable the
automatic installation of pending patches on reboot.
Thoughts?
-Steve L.
On Tue, Aug 19, 2008 at 01:03:55PM -0700, Jordan Brown wrote:
> Bob Netherton wrote:
> > And further
> > refinement would only impact patching rather than the booting process
> > as a whole.
>
> Hmm. I don't know how to have a service that runs when a particular
> milestone is selected, that *doesn't* run when "all" is selected.
> (Other than by dynamically enabling and disabling it.)
>
> > rc scripts doing things with SMF seem a permanent solution to a
> > temporary problem. In my virtual universe there are no rc scripts :)
> > And then the alarm clock goes off and I return to reality. But it does
> > promote rc hackery rather than fixing the problem in SMF where it
> > belongs.
>
> Agreed. Besides, I believe that SMF is locked while rc scripts are
> running, and that any attempt to manipulate it deadlocks.
>
> There are related schemes that could work, but the problem is getting
> them properly sequenced into system startup.
>
> > reboot -- -m milestone=patchinstall seems elegantly simple.
>
> Plausible, though it doesn't exactly fit the current application usage
> model. At the moment, the reboot might or might not be triggered by the
> patching application. The patching application leaves the system set up
> to do the patching at the next shutdown/reboot, whenever that might be.
> (For SunUC-S's shutdown-time processing, it's require that that reboot
> be via the "clean" mechanisms - init, shutdown - so that the processing
> gets done.)
>
> This scheme would require either
>
> 1) having the patch application set the default milestone, and then
> having the startup-time processing set it back, or
> 2) having the patch application do the reboot.
>
> There's still the issue with how to keep this service from running when
> you boot to "all".
>
> Hmm. How does single-user-mode login work? What stops it from running
> on a normal boot? Is it a special case?
>
> ---
>
> BTW: I'm not in a position to commit the patch applications. I'm in
> the middle here because I'm relatively familiar with all of the players
> and the issues, but in my day job I'm not responsible for *any* of them.
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
