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
zones-discuss@opensolaris.org
