I believe the original concern about making system/filesystem/local part 
of single-user was that it changes the definition of single-user.  The 
zones team was involved in that discussion, and I've just tried to 
re-involve them in the resolution discussions.  (And have cc'ed them 
here.  Apologies for the crosspost.)  It may just be morning, but I'm 
currently having a hard time finding that argument too compelling on its 
own -- it seems there must have been something more specific.

Creating a patch milestone has previously been my preferred direction 
(as it requires actual definition and design of what the patching 
frameworks need, rather than just hoping that single user is 
appropriate), but I'm no longer certain this is a sensible investment, 
as my understanding of IPS is that they're sticking to their guns and 
there will be no live patching of the OS that leads us to these types of 
scenarios.  Thankfully.

Given that, I wonder if a different option is to confirm that 
system/filesystem/local is idempotent (and not already running), and 
then have patchadd just run its method directly.  It leaves a bad taste 
in my mouth, but then again so does the fact that we've got two 
different patching systems which require the system to be in different 
states when they run.

But, again, I think the zones team explored many of these options in the 
first round and would like to make sure they have a chance to weigh in.

liane  (in theory, on vacation today.)

Renaud Manus wrote:
> A solution could be to move system/filesystem/local in the single-user
> milestone.
> -- Renaud
> Jordan Brown wrote:
>> Could some SMFers please weigh in on 6725004 and give some opinions on 
>> how best to address it?
>> Here's a summary of the problem:
>> Sun Update Connection Enterprise attempts to install "single-user" 
>> patches using an rcS.d script.  This has historically been a problem, 
>> since zone roots may not have been mounted yet.  Patchadd was recently 
>> changed to partially work around this problem, by enabling 
>> system/filesystem/local, but when that mechanism is triggered from an 
>> rcS.d script (or, presumably, from a service on which 
>> milestone/single-user depends), it yields a deadlock - 
>> system/filesystem/local can't be run, because milestone/single-user 
>> hasn't been reached.  (This is, I believe, in addition to the technical 
>> issues surrounding performing SMF operations from an rcS.d script.)
>> I believe that the most truly correct way to address this problem is to 
>> have a deferred patching service that depends on 
>> system/filesystem/local, and on which all other later services depend. 
>> However, I think the only way to implement such a service would be to 
>> modify the dependencies of those later services, and that seems awkward. 
>>   (One could also rename system/filesystem/local, retain the original 
>> name as something of a milestone, and insert the deferred patching 
>> service as a new service between the renamed s/f/l and the original 
>> s/f/l, but that  seems quite ugly.)
>> _______________________________________________
zones-discuss mailing list

Reply via email to