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

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
3. Create patch-install service, which depends on:

   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

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.


-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 mailing list

Reply via email to