AIX常见故障报错及解决方案

1、 AIX 常见故障报错及解决方案 大多数情况下，顺着报错顺藤摸瓜很快就能找出原因，但总有例外，有些报错信息或者日志恰恰让我们南辕北辙。让我们看看这些案例最终是如何处理的案例1：图省事，搞出来个大麻烦生产中心有几套VIOS环境，正常运行了1-2年，今日发现有2套进行健康性检查，发现执行命令就hang在哪里不动了，又是内存不够用了。0403-031 The forkfunction failed. There is not enough memory available.好奇怪，到底内存被谁用了，vios好端端的就这样了。都这个样子，重启vios分区吧。重启完，vios顺利登陆，执行健康性检查没啥

2、问题，可是用nmon看了一下内存使用分配了4个G，使用1个多G,慢慢慢慢的就看到内存使用越来越大，不一会4个G就用完了，重启其他vios分区一个样子，连换页空间都用了。顿时一头雾水。到底发生了什么呢？生产中心有几套VIOS环境，正常运行了1-2年.突然出现这种问题，首先想到的是变更。梳理了近期变更操作，近期新部署了PowerVC,VIOS进行了补丁升级。VIOS2.1升级到VIOS2.2.3.首先，重启vios分区，在内存没有用完前赶紧检查那个进程使用的内存.排名第一的是vio_daemon,观察了一会发现内存一会就被他占用完了第二，元凶找到了，vio_daemon到底是干啥的，问问IBM80

3、0吧，IBM回复问我收集一下系统信息。1.ioslevel2./etc/security/limits的输出反馈后，IBM告诉我，我遇到了bugvios版本和 /etc/security/limits stack = -1完全符合这个bug特征。其实这个bug是可以避免的，我们大多数实施AIX的时候,很容易顺手把 /etc/security/limits.都改成-1，在大多数情况下，没啥问题，但是就是在这个版本下就容易遇到这个问题。default: fsize = -1 core = -1 cpu = -1 data = -1 rss = -1 stack = -1 nofiles = -1T

4、he problem can be due to a known issue inVIOS thru with vio_daemon having a memory leak that was fixedat with IV64508,or it could be due to incorrect VIOS settings.AnswerTo check your VIOS level, as padmin, run:$ ioslevelIf your VIOS level is or higher, the problem ma

5、y be due to the VIOShaving incorrect system settings in /etc/security/limits. If thestack size is set to unlimited (stack = -1),this exposes a condition where the system can be allowed to pin as much stackas desired causing vio_daemon to consume a lot of memory.$ oem_setup_envvi /etc/security/limits

6、 -check thedefault stanzadefault:fsize = -1core = -1cpu = -1data = -1rss = -1stack = -1nofiles = -1In some cases, the issue with vio_daemonconsuming high memory is noticed after a VIOS update to 2.2.3.X. However, aVIOS update will NOT change these settings. It is strongly recommended not tomodify th

7、ese default values as doing so is known to cause unpredictableresults. Below is an example of the default values:default:fsize = 2097151core = 2097151cpu = -1data = 262144rss = 65536stack = 65536nofiles = 2000To correct the problem change the setting back to default values.Then reboot the VIOS at yo

8、ur earliest convenience.案例2：装个AIX，却装出了信任危机某制造业用户，一个新项目着急要上线，让维保厂商工程师赶紧抓紧准备一个AIX资源，装AIX系统按说对ma工程师来讲应该轻车熟路，可是这次装了好几遍，AIX系统就是进不去。1 怀疑光盘问题，更换好几张重装未果，依旧进不去2 怀疑AIX版本，更好了两个未果3 怀疑硬件，进入asm里也没啥报错首先说下用户设备的背景信息，设备采购于2012年，“天工计划”中的一款产品Power710 和Power730 中的一款，Power710设备特点：定位应用服务器，价格便宜，也就是不需要HMC管理，使用串口安装的IVM部署管理虚拟

9、化环境。之前这台710用作应用服务器。串口部署过IVM环境，这次重装需要注意串口输出问题。所以一定要进行如下配置才可以顺利进入系统第一步：进入维护模式 如果进入 Maintenance Mode 步骤就省略了第二步：#export TERM=vt100# smit chtty红色标注的两行，增加clocal.syncsyncsyncreboot之后就能顺利进行系统了。案例3：安装AIX报出这个错，新手老手绝对没见过相信社区大多数人都安装AIX几十遍甚至上百遍了，但是今天安装AIX报出这个错，新手老手绝对没见过安装AIX停在了这里。其实我也经过了很多各位的排查工作，最终梳理了一下发现AIX安装出

10、问题，排除硬件介质问题，多半是配置问题，那就按照这个思路往下走首先，既然是配置就去profile文件里看看。不查不知道，一查问题果然找到了有人会说，你居然犯这么低级的错误。冤枉啊，这是PowerVC干的怪我背景没说清楚。这是PowerVC部署aix出现的问题.第二，问题找到了，那么为什么会出现问题，部署分区profile配置是在Powervc设置的，那就去Powervc里找答案吧。问题出在了这里.PowerVC纳管了很多主机，每台主机配置不尽相同，当初为了省事就配置了vary计算模板，最大cpu配置成了32。实际部署AIX时候，选择了一台低配的power服务器，CPU配置没有32，只有20个，

11、结果被PowerVC配置成25.6.就这样出现了问题。反思这个问题，PowerVC,规划配置模板，尽量多配置几个计算模板，与服务器相匹配.避免此类问题的发生。通过这个问题还有第二种解法：kdb模式下 输入 f，查看堆栈信息，也可以顺势查到profile配置信息案例4：执行lsrep，诡异报出Insufficient memory执行lsrep，诡异报出Insufficient memory检查vios分区内存使用情况似乎跟内存毫无关系。首先检查了其他vios有没有这个问题，发现均没有此现象发生。对比vios版本及其lsrep输出，发现vios版本。都一样，唯一不同的是出问题的这个vios /v

12、ar/vio/VMLibrary没有iso。把几个AIX ISO传到有问题的这个vios /var/vio/VMLibrary下后，再次执行lsrep，成功了案例5：PowerHA给Oracle新增表空间，遭遇memory croedump通过PowerHA给Oracle新增表空间，使用C-SPOC在线添加LV,开始给Datavg添加，很顺利，添加了10个很成功，在继续添加新的lv后，居然报错了. memory croedump.1，内存不够用了吗.看了一下确实有点紧张hostA:hostB:2，仔细看了一下Powerha日志也没啥有价值的信息难道真的是内存快用完了导致的。3，由于还要给其他v

13、g新增lv，所以又尝试了一下给其他vg添加一下lv试试。居然成功了。这个问题从内存报错开始容易给人内存不足假象，实际环境确实也是内存利用率很高，但是定位最终问题不是内存不足造成的。首先，刚开始新增的几个lv都顺利，后几个就失败了，然后新增其他vg的lv也成功了，这个时候就开始怀疑遇到bug了。第二，一般裸奔的powerha，遭遇bug的可能性比较大，检查一下powerha补丁情况吧果然，基本上就是一个裸奔的Powerha环境，遇到bug也就不足为奇了第三，既然怀疑是bug，那就找点说服力的东西出来.如下所示IV36992: CLPASSWDREMOTE CORE DUMPS DUE TOMEM

14、ORY FAULTA fix is availableObtain the fix forthis APAR.Error descriptionThe clpasswdremote utility is core dumping due tosegmentationfault.The problem occurs when the user is missing in/etc/passwdin one of the nodes in the cluster.The cspoc.log will log the following:= C_SPOC COMMAND LINE=/usr/es/sb

15、in/cluster/sbin/cl_chpasswd -cspoc-f -r-cspoc -grg1 test3hacmp13: success:/usr/es/sbin/cluster/etc/clpasswd/usr_bin_passwd.origtest3hacmp14: FAILED: evalclpasswdremote -u test3 -praCYOSMwhoJU. -f 2 -l 0hacmp14: cexec54: 3735594 Memoryfault(coredump)hacmp14: RETURN_CODE=139hacmp14: cl_rsh had exit co

16、de =139, see cspoc.logand/or clcomd.log for more informationThe error report will log a CORE DUMP error with thefollowing stack trace:main 94main 88_start 6CThe following symptom code is logged as well:PIDS/5765E6200 LVLS/520 PCSS/SPI2 FLDS/clpasswdr SIG/11FLDS/mainVALU/94 FLDS/_startLocal fixEnsure

17、 that the user exists in /etc/passwd file in all ofthe nodes in the cluster.Problem summaryIf a user is not created using cspoc so that it exists onall nodes in the cluster, then if you try to change thatusers password cluster wide using cspoc, clpasswordremotewill core dump on nodes where the user

18、is not configured.The smit output will look like:Changing password for tstuserhack2: cexec 54 : 8781858 Memory fault(coredump)Problem conclusionA check was added to clpasswdremote to avoid attempting tochange the password on a node where the user is not defined.案例6：V7000紧急的状态，紧急的处理使用PowerVC,部署AIX分区，

19、结果无法部署，报了一堆莫名其妙的错误。怪了前几天还能正常部署.今天就不能了检查PowerVC服务都正常.登录HMC看看有没有建立分区profile，发现没有.无功而返，返回PowerVC继续排查，到了存储器发现了端倪，不过看样子挺吓人。V7000存储卷运行状况变成了紧急。登录V7000查看，发现V7000没有问题。那就怪了。其实PowerVC里的关于V7000的状态 紧急不能反映V7000真正的状态，而是通信出现了导致。至于通信出现问题，事后问网络的人，我部署的期间，网络正在变更，导致PowerVC不能下发命令给V7000，PowerVC就把V7000标记成紧急了。案例7：一次先入为主的异常故

20、障处理！一台P740服务器通过SAN交换机链接一台DS4700存储，在硬件维保商更换一次存储电池（A控）后，业务中断了。我司负责数据库以及系统维护，被客户CALL到现场检查问题，在一番查看后发现A控上面所有LUN都找不到了，问题找到后开始排查问题。询问硬件维保商在更换电池时有没有动到其他东西，得到了很准确的回答，我们就换个电池其他啥也没用动。于是连接存储SM把A控所有LUN切到B控，系统内能看到所有盘，OK 问题在A控上面，SM中看到的存储无报错无问题，继续把原来A控的LUN切到A控中，系统又找不到了开始删除所有硬盘然后重新识别还是不行忙来忙去 两三个小时过去了，客户在旁边一直说啥时候能搞好啊

21、，硬件维保商的人没事似的在旁边坐着我要去机房看一下，必须看一下。客户带着我们下了机房，然后看了主机以及HBA卡连接线，一切看起来都那么美好。然后看到了存储A控出的那条光纤线你妈的插错了！ 客户用异样的眼光看着硬件维保商处理问题切勿先入为主，任何事要自己确定一下以免有误！案例8：varyonvg报错(LVM相关)的分析及处理AIX操作系统在做计划内升级操作系统版本变更时，发现对于VG的varyon和varyoff命令有告警信息，经分析这只是一个告警信息，不影响使用，具体告警信息如下：系统环境：AIX 5.3 TL12 SP7首先，分析当时的报错内容，从操作内容来看，可以看到在执行varyoffv

22、g命令时底层调用lqueryvg子命令时报错，而lqueryvg是一个查询类的命令，从这个命令的返回内容说明VG的定义信息与VGDA描述不一致。对于这类型的告警信息，重启操作系统时便会自动更新VG的相关信息进行自动修正。而当时计划内的变更是升级操作系统并修改磁盘的reserve_policy属性，因此打完补丁后直接重启操作，在这个过程中已经把VG信息进行了更新。然后，分析当时的操作步骤及LVM的日志进行验证对应。当时的操作记录如下，从操作日志来看，在重启操作系统前执行过两次varyoffvg和一次varyonvg的操作：分析当时的LVM的日志，可以看到第一次varyoffvg时出现读取VG信息不一致的报错。在第一次varyonvg时出现现样的信息。在第二次varyoffvg时也现现同样的信息。上面信息是操作系统重启前的信息，下面分析操作系统重启后LVM相关的信息，从日志中来看，当操作系统重启后，VG在varyon时返回值为0，说明重启过程已经更新了VG的信息。综上所述，在重启操作系统后已经自动更新