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.) >> _______________________________________________
