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

Reply via email to