On Thu 23 Apr 2009 at 01:06PM, Ben Rockwood wrote: > Jerry Jelinek wrote: > > Ben Rockwood wrote: > >> One issue I did smack into that I don't fully understand yet is the > >> syseventd service failing within the zone. I'm still trying to hash out > >> how to solve that. > > > > Ben, > > > > The sysevent service should not run in the ngz. > > This is delivered in a hollow pkg with svr4 pkging. > > You might take a look at my p2v webrev for opensolaris. ... > > Excellent! That explains things. I know that syseventd doesn't run in > zones, but in the past I've seen SMF scripts simply exiting if it was in > a ngz, I wasn't sure how this was handled.
Well, it doesn't actually explain why you're in this situation. Jerry-- shouldn't it be the case that we don't even deliver this into the ipkg zone? I was surprised by Ben's mail initially because IPS support for variants should mean that the sysevent service is not delivered in the zone when installed: $ zonename global $ pkg search /var/svc/manifest/system/sysevent.xml INDEX ACTION VALUE PACKAGE path file var/svc/manifest/system/sysevent.xml pkg:/sunw...@0.5.11-0.111 $ pkg contents -m SUNWcsd | grep sysevent.xml file 59577d5adb8f6609814cf693b79f80001ebe3b6c chash=86217745abacf6ada215c19c29b411567a3422e2 group=sys mode=0444 ----->opensolaris.zone=global ... ----->variant.opensolaris.zone=global So I'm perplexed how this service could wind up in the zone-- unless the variant isn't getting set properly in the image? Or perhaps the mixing of a very new version of SUNWipkg with older repository contents is causing this to not work right... I'm not certain. -dp -- Daniel Price, Solaris Kernel Engineering http://blogs.sun.com/dp _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org