On 22/02/2010 19:38, Alan Maguire wrote: > On 22/02/2010 19:33, Tony Nguyen wrote: >> 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. >> > great stuff, thanks for the help guys! I _think_ > I may have an interim fix too - we were unconditionally > enabling the location service in nwam's start method > even if it doesn't exist yet (which is the case on first > boot post-BFU), so I reckon checking for existence first > should solve this in the short term. I should have > confirmation if this works or not in the next few hours. > quick follow-up - adding the service existence check sorted things out. Thanks again for the help!
Alan
