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

$ pkg search /var/svc/manifest/system/sysevent.xml
INDEX      ACTION    VALUE                     PACKAGE
path       file      var/svc/manifest/system/sysevent.xml 

$ pkg contents -m SUNWcsd | grep sysevent.xml
        file 59577d5adb8f6609814cf693b79f80001ebe3b6c
        chash=86217745abacf6ada215c19c29b411567a3422e2 group=sys mode=0444
  ----->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.


Daniel Price, Solaris Kernel Engineering    http://blogs.sun.com/dp
zones-discuss mailing list

Reply via email to