06-19-2014 03:36 PM
we are upgrading a solaris 10 media server from 7.5.0.6 to 7.6 and then to 7.6.0.2. in the upgrade from 7.5.0.6 to 7.6 we are noticing the install script takes forever during the preinstall check phase.
in looking under the covers i can see that it is running nbtelemetry and then nbcheck. each of which takes about an hour to complete. in truss-ing these commands i can see it going thru a long series of stat system calls on files in /net/nbtools/..... which each take about a minute to timeout since these would be automounted nfs shares that do not exist. IE:
stat("/net/nbtools/tools/perl/5.16.1/app/SunOS_5.10_sparc_SunS_5.8/lib/site_perl/5.16.1/sun4-solaris-thread-multi-64/auto/List/Util", 0x1002A69E8) (sleeping...)
stat("/net/nbtools/tools/perl/5.16.1/app/SunOS_5.10_sparc_SunS_5.8/lib/site_perl/5.16.1/sun4-solaris-thread-multi-64/auto/List/Util", 0x1002A69E8) Err#2 ENOENT
using grep on nbcheck and nbtelemetry, i see 53 references to /net/nbtools. both of these executables are coming from the latest NetBackup_7.6.0.1_Solaris_Sparc64.tar.gz download.
has anyone else seen this. it seems like someone must have encountered this in the past.
thanks,
al
Solved! Go to Solution.
06-19-2014 04:42 PM
I have never on 7.6, but have experience similar issue in previous release that some binary run long time trying to access nfs throgh /net automount. Root case of this issue is insifficient binary build that result in adding insufficient library serach path. You dhould open a case with Symantec.
For workaround, check host entry in nsswitch.conf first. In my case, the host suffered refers DNS but no DNS connectivity at that time. This brings long turnaround time when users/processes try to access /net/<hostname> path. Then consider to disable dns from host entry in nsswitch.conf, or to add dummy entry for "nbtools" in hosts file.
06-19-2014 04:42 PM
I have never on 7.6, but have experience similar issue in previous release that some binary run long time trying to access nfs throgh /net automount. Root case of this issue is insifficient binary build that result in adding insufficient library serach path. You dhould open a case with Symantec.
For workaround, check host entry in nsswitch.conf first. In my case, the host suffered refers DNS but no DNS connectivity at that time. This brings long turnaround time when users/processes try to access /net/<hostname> path. Then consider to disable dns from host entry in nsswitch.conf, or to add dummy entry for "nbtools" in hosts file.
06-20-2014 08:42 AM
Thanks fior your suggestion, i was heading down the same path. i added nbtools to /etc/hosts as 127.0.0.1 and nbcheck just rips thru those stat system calls to /net/nbtools.
Al