On Tue, May 24, 2011 at 12:49:37PM +1200, Tim Foster wrote:
> Hi there,
>
> I've got a short webrev here for some nasty zones breakage that I'd
> appreciate a review of please:
>
> http://cr.opensolaris.org/~timf/zones-fix-webrev
>
> I've only occasionally seen the 'boot' brand script hit this problem,
> but sysboot hits it all the time (tested using a collection of 8 zones,
> all set to either autoboot, or not autoboot, respectively)
>

hey tim,

sorry i didn't reply to your other emails yet.

this fix looks good to me.

but at this point i'm not totally sure what the right answer is long
term here.

with the current async behavior during boot, i fear we're setting
ourselves up for a race because when zoneproxyd starts up it scans for
zones, then after that it expects notifications during zoneboot when a
zone is starting up.  this works if zoneproxyd is started before or
after the zones service, but not if it's started at the same time.

one option would be to make the zones service dependent upon the zones
proxy via an 'optional_all' dependency delivered via the zoneproxy
service.  this would work like zones-monitoring service.  (which has a
similar race to the one we're dealing with here.)  but i don't know how
this would respond to the deadlock problem we're talking about here if
the zone-proxy was disabled and we tried to enable it while inside the
zones service start method.

another option would be to make the zones service dependent upon the
zones proxy via a 'require_all' dependency delivered via the zoneproxy
service.  this would mean that we'd never have to manually enable the
zones proxy service like we do today, but it would also probably mean
that the zones proxy service would have to be shipped as enabled and
always be enabled on all systems.

i guess a final option would be to simply make the two services
independent, and just leave the service auto-start code that we have
today in place.

but like i said, i'm not sure what the right answer is here.  :(

ed
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to