On 02/22/10 10:01 AM, Alan Maguire wrote: > On 22/02/2010 17:56, Tony Nguyen wrote: >> On 02/22/10 09:49 AM, Alan Maguire wrote: >>> On 22/02/2010 17:26, Sean Wilcox wrote: >>>> Alan Maguire wrote: >>>>> hi folks >>>>> >>>>> I was wondering if there have been any other cases where the >>>>> above has been observed - a valid manifest appears to >>>>> be imported, a manifest hash that looks correct is present >>>>> (ensuring that reimport won't work until we delete the >>>>> service with "svccfg delete -f") but property groups are >>>>> missing (specifically the service dependencies, dependents >>>>> and all its methods - start,stop,refresh). I can't see any complaints >>>>> in the manifest-import or startd logs, the former actually seems to >>>>> be adding the relevant manifest, with the following line in the log: >>>>> >>>>> add_manifest network/location >>>>> /var/svc/manifest/network/network-location.xml >>>>> >>>>> Even if I delete the manifest hash propertygroup in smf/manifest, >>>>> the service is reimported but the properties still don't appear - >>>>> a delete -f on the service is required to get the properties back. >>>>> Are there any known manifest-import issues that might explain >>>>> this? Is there any more info I can collect that might help shed light >>>>> on what's going on? It doesn't appear that startd or configd >>>>> have died - no corefiles appear etc. BTW we're seeing this for the >>>>> first time since merging with snv_134, and after fresh install to >>>>> recent >>>>> Nevada build + BFU of project bits, but on sparc only. >>>>> >>>>> Thanks! >>>>> >>>>> Alan >>>>> _______________________________________________ >>>>> smf-discuss mailing list >>>>> smf-discuss at opensolaris.org >>>>> >>>>> >>>> If you manually import the service with svccfg -v import <manifest> >>>> any additional information given? >>>> >>> Yep, manual import works fine - see below for >>> output. >>> >>>> When you say recent Nevada build, what is that build? >>> The base build (installed via JumpStart) was snv_130, on >>> top of which I bfu'ed project bits synced with snv_134. >>>> The reason the add_manifest message is something that's >>>> added if you are not using a recent svccfg to import the manifest, >>>> because it's not getting the manifestfile <-> service >>>> connection created via svccfg, but manifest-import is upgrading the >>>> service to make that connection. >>>> >>> Hmm, the weird thing is though that even post-BFU, >>> if I delete the location service and reboot, these properties >>> are still missing after re-import. However if I "svccfg delete -f" >>> and manually "svccfg import", rather than via manifest-import, >>> all is well. Here's an example of where I "svccfg delete -f" and >>> reboot. >>> The properties are missing,but when I "svccfg delete -f" and manually >>> "svccfg import", they appear. When I "svccfg delete -f" and reboot, >>> I see: >>> >>> Loaded 1 smf(5) service descriptions >>> >>> ...in the manifest-import log. >>> >>> And after removal + reboot of the location service, >>> the properties look like this: >>> >>> # svcprop location >>> location_netcfg/entities fmri svc:/network/netcfg >>> location_netcfg/external boolean true >>> location_netcfg/grouping astring require_all >>> location_netcfg/restart_on astring none >>> location_netcfg/type astring service >>> general/enabled boolean false >>> restarter_actions/auxiliary_tty boolean false >>> restarter_actions/auxiliary_fmri astring svc:/network/physical:nwam >>> restarter_actions/refresh integer >>> general_ovr/enabled boolean true >>> restarter/auxiliary_state astring none >>> restarter/logfile astring /var/svc/log/network-location:default.log >>> restarter/next_state astring none >>> restarter/state astring online >>> restarter/state_timestamp time 1266860005.834828000 >> >> Is the location service delivered enabled? It looks like location >> service is enabled by another service. >> > It's delivered disabled since it's only used if NWAM is > running. If the network/physical:nwam is enabled, it > will in turn enable network/location. On first reboot > post-upgrade, physical:nwam will try and enable -t > location:default, and since manifest-import > has not run, the latter is not present. Could this be a > factor? Thanks! > > Alan
Ah, I should have seen physical:nwam in the auxiliary_fmri property. This is similar to the bug we discovered during Early Import testing. Properly imported service instances are expected to have last-import snaphots which svccfg import uses to perform property upgrades. When a service is missing last-import snapshots but have 'enabled' properties, svccfg import assumes such service to be properly imported and only generated last-import snapshot for it. That is, last-import snapshot capable svccfg was introduced after the initial integration of SMF thus we simply upgrade services by adding last-import snapshot. When a service created by dependent definition, network/netcfg defines location service as dependent, location service doesn't have a last-import snapshot. physical:nwam comes along and enables location which populated location's general/enabled property. Since location service is missing last-import snapshot but it has general/enabled property, svccfg import would not properly import the service. The good news is that Early Manifest Import will solve this issue. -tn
