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