On 02/22/10 01:57 PM, Alan Maguire wrote: > 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
Cool. Glad you got it sorted out. -tn
