Johan Sunnerstig writes: > I have a(probably trivial) problem with a manifest. > I need to bring up another default route for a zone that'll have a virtual in > terface in another network than the global zone. > I can't do this before the zone is booted, since before then, the system won' > t be connected to the network where this second gateway resides, hence throwi > ng me a "network unreachable" error. > > So I was looking around, and found this thread: > http://www.opensolaris.org/jive/thread.jspa?messageID=10877&; > > So, I figured I'd customize his script slightly to make it depend on the zone > service, and also just change the service and file names to reflect that thi > s is only used for setting default routes for local zones.
... > When the box reboots, the zone service comes up as it should(that is, take sl > ightly longer than the rest of the system, maybe 20 seconds or so at most), b > ut the zones-default-routes service lands in a maintenance state straight awa > y(or as straight away as I can login anyway). > Just doing a "svcadm clear zones-default-routes" after the zones service is u > p adds the route and brings the service to Online as expected. The zones service doesn't guarantee today that the zones are completely started by the time it returns. If the route command throws a helpful error when the network isn't there, you can confirm this by: "svcs -x zones-default-routes", look for the logfile, and see if the contents of the logfile validates my assumption. My best suggestion at this point is to modify your service's startup method to explicitly wait on the condition you need to be true -- that the network you need is available. (Surely Jim will come tell me why this is a bad solution in the world of unreliable networks, but hopefully he'll also show up with a better suggestion. :) ) liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
