checksig(checksig函数用法)

　　以下内容来自社区活动“精准解决AIX上诡异报错问题的处理思路”，分享者社区会员孙伟光、张彬等

　　大多数情况下，顺着报错顺藤摸瓜很快就能找出原因，但总有例外，有些报错信息或者日志恰恰让我们南辕北辙。都说老司机经验多，见多识广，但是遇到下面的这些案例，相信再老的司机也未必能从容面对。让我们看看这些案例最终是如何处理的……

　　案例1checksig：图省事，搞出来个大麻烦

　　生产中心有几套VIOS环境，正常运行了1-2年，今日发现有2套进行健康性检查，发现执行命令就hang在哪里不动了，又是内存不够用了。

　　"0403-031 The fork

　　function failed. There is not enough memory available."

　　好奇怪，到底内存被谁用了，vios好端端的就这样了。都这个样子，重启vios分区吧。重启完，vios顺利登陆，执行健康性检查没啥问题，可是用nmon看了一下内存使用分配了4个G，使用1个多G,慢慢慢慢的就看到内存使用越来越大，不一会4个G就用完了，重启其checksig他vios分区一个样子，连换页空间都用了。顿时一头雾水。到底发生了什么呢checksig？

　　生产中心有几套VIOS环境，正常运行了1-2年.突然出现这种问题，首先想到的是变更。梳理了近期变更操作，近期新部署了PowerVC,VIOS进行了补丁升级。VIOS2.1升级到VIOS2.2.3.

　　首先，重启vios分区，在内存没有用完前赶紧检查那个进程使用的内存.

　　排名第一的是vio_daemon,观察了一会发现内存一会就被checksig他占用完了

　　第二，元凶找到了，vio_daemon到底是干啥的，问问IBM800吧，IBM回复问我收集一下系统信息。

　　1.ioslevel

　　2./etc/security/limits的输出

　　反馈后，IBM告诉我，我遇到了bug

　　vios版本和 /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 = -1

　　The problem can be due to a known issue inVIOS 2.2.3.0 thru 2.2.3.3 with vio_daemon having a memory leak that was fixedat 2.2.3.4 with IV64508,or it could be due to incorrect VIOS settings.

　　Answer

　　To check your VIOS level, as padmin, run:

　　$ ioslevel

　　If your VIOS level is 2.2.3.4 or higher, the problem may be due to the VIOShaving incorrect system settings in /etc/security/limits. If the"stack" 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_env

　　vi /etc/security/limits ->check thedefault stanza

　　default:

　　fsize = -1

　　core = -1

　　cpu = -1

　　data = -1

　　rss = -1

　　stack = -1

　　nofiles = -1

　　In 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 these default values as doing so is known to cause unpredictableresults. Below is an example of the default values:

　　default:

　　fsize = 2097151

　　core = 2097151

　　cpu = -1

　　data = 262144

　　rss = 65536

　　stack = 65536

　　nofiles = 2000

　　To correct the problem change the setting back to "default" values.Then reboot the VIOS at your earliest convenience.

　　案例2：装个AIX，却装出了信任危机

　　某制造业用户，一个新项目着急要上线，让维保厂商工程师赶紧抓紧准备一个AIX资源，装AIX系统按说对ma工程师来讲应该轻车熟路，可是这次装了好几遍，AIX系统就是进不去。

　　1 怀疑光盘问题，更换好几张重装未果，依旧进不去

　　2 怀疑AIX版本，更好了两个未果

　　3 怀疑硬件，进入asm里也没啥报错

　　首先说下用户设备的背景信息，设备采购于2012年，天工计划(IBM 2010年8月推出的“天工计划” ，通过全面整合其硬件、软件、实验室、渠道大学、合作伙伴部的丰富资源，帮助IBM在UNIX市场的未来进一步扩大领先优势)中的一款产品Power710 和Power730 中的一款，Power710.设备特点：定位应用服务器，价格便宜，也就是不需要HMC管理，使用串口安装的IVM部署管理虚拟化环境.

　　之前这台710用作应用服务器。串口部署过IVM环境，这次重装需要注意串口输出问题.

　　所以一定要进行如下配置才可以顺利进入系统

　　第一步：进入维护模式 如果进入 Maintenance Mode 步骤就省略了

　　第二步：#export TERM=vt100

　　# smit chtty

　　红色标注的两行，增加clocal.

　　sync sync sync reboot

　　之后就能顺利进行系统了。

　　案例3：安装AIX报出这个错，新手老手绝对没见过

　　相信社区大多数人都安装AIX几十遍甚至上百遍了，但是今天安装AIX报出这个错，新手老手绝对没见过

　　安装AIX停在了这里。

　　其实我也经过了很多各位的排查工作，最终梳理了一下发现AIX安装出问题，排除硬件介质问题，多半是配置问题，那就按照这个思路往下走

　　首先，既然是配置就去profile文件里看看。不查不知道，一查问题果然找到了

　　有人会说，checksig你居然犯这么低级的错误。冤枉啊，这是PowerVC干的怪我背景没说清楚。这是PowerVC部署aix出现的问题.

　　第二，问题找到了，那么为什么会出现问题，部署分区profile配置是在Powervc设置的，那就去Powervc里找答案吧。

　　问题出在了这里.PowerVC纳管了很多主机，每台主机配置不尽相同，当初为了省事就配置了vary计算模板，最大cpu配置成了32。

　　实际部署AIX时候，选择了一台低配的power服务器，CPU配置没有32，只有20个，结果被PowerVC配置成25.6.就这样出现了问题。

　　反思这个问题，PowerVC,规划配置模板，尽量多配置几个计算模板，与服务器相匹配.避免此类问题的发生。

　　通过这个问题还有第二种解法：

　　kdb模式下 输入 f，查看堆栈信息，也可以顺势查到profile配置信息

　　案例4：执行lsrep，诡异报出Insufficient memory

　　执行lsrep，诡异报出Insufficient memory

　　检查vios分区内存使用情况

　　似乎跟内存毫无关系。

　　首先检查了其他vios有没有这个问题，发现均没有此现象发生。对比vios版本及其lsrep输出，发现vios版本。都一样，唯一不同的是出问题的这个vios /var/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 由于还要给其他vg新增lv，所以又尝试了一下给其他vg添加一下lv试试。

　　居然成功了。

　　这个问题从内存报错开始容易给人内存不足假象，实际环境确实也是内存利用率很高，但是定位最终问题不是内存不足造成的。

　　首先，刚开始新增的几个lv都顺利，后几个就失败了，然后新增其他vg的lv也成功了，这个时候就开始怀疑遇到bug了。

　　第二，一般裸奔的powerha，遭遇bug的可能性比较大，检查一下powerha补丁情况吧

　　果然，基本上就是一个裸奔的Powerha环境，遇到bug也就不足为奇了

　　第三，既然怀疑是bug，那就找点说服力的东西出来.如下所示

　　IV36992: CLPASSWDREMOTE CORE DUMPS DUE TOMEMORY FAULT

　　A fix is available

　　Obtain the fix forthis APAR.

　　Error deion

　　The clpasswdremote utility is core dumping due to

　　segmentation

　　fault.

　　The problem occurs when the user is missing in

　　/etc/passwd

　　in one of the nodes in the cluster.

　　The cspoc.log will log the following:

　　[========== C_SPOC COMMAND LINE==========]

　　/usr/es/sbin/cluster/sbin/cl_chpasswd -cspoc-f -r

　　-cspoc -grg1 test3

　　hacmp13: success:

　　/usr/es/sbin/cluster/etc/clpasswd/usr_bin_passwd.orig

　　test3

　　hacmp14: FAILED: eval clpasswdremote -u test3 -p

　　'raCYOSMwhoJU.' -f 2 -l 0

　　hacmp14: cexec[54]: 3735594 Memoryfault(coredump)

　　hacmp14: RETURN_CODE=139

　　hacmp14: cl_rsh had exit code =139, see cspoc.log

　　and/or clcomd.log for more information

　　The error report will log a CORE DUMP error with the

　　following stack trace:

　　main 94

　　main 88

　　__start 6C

　　The following symptom code is logged as well:

　　PIDS/5765E6200 LVLS/520 PCSS/SPI2 FLDS/clpasswdr SIG/11

　　FLDS/main

　　VALU/94 FLDS/__start

　　Local fix

　　Ensure that the user exists in /etc/passwd file in all of

　　the nodes in the cluster.

　　Problem summary

　　If a user is not created using cspoc so that it exists on

　　all nodes in the cluster, then if you try to change that

　　user's password cluster wide using cspoc, clpasswordremote

　　will core dump on nodes where the user is not configured.

　　The smit output will look like:

　　Changing password for "tstuser"

　　hack2: cexec 54 : 8781858 Memory fault(coredump)

　　Problem conclusion

　　A check was added to clpasswdremote to avoid attempting to

　　change the password on a node where the user is not defined.

　　案例6：V7000紧急的状态，"紧急"的处理

　　使用PowerVC,部署AIX分区，结果无法部署，报了一堆莫名其妙的错误。怪了前几天还能正常部署.今天就不能了检查PowerVC服务都正常.登录HMC看看有没有建立分区profile，发现没有.无功而返，返回PowerVC继续排查，到了存储器发现了端倪，不过看样子挺吓人

　　V7000存储卷运行状况变成了紧急。登录V7000查看，发现V7000没有问题。那就怪了。

　　其实PowerVC里的关于V7000的状态 紧急不能反映V7000真正的状态，而是通信出现了导致。至于通信出现问题，事后问网络的人，我部署的期间，网络正在变更，导致PowerVC不能下发命令给V7000，PowerVC就把V7000标记成紧急了。

　　案例7：一次先入为主的异常故障处理！！

　　一台P740服务器通过SAN交换机链接一台DS4700存储，在硬件维保商更换一次存储电池（A控）后，业务中断了。

　　我司负责数据库以及系统维护，被客户CALL到现场检查问题，在一番查看后发现A控上面所有LUN都找不到了，问题找到后开始排查问题。

　　询问硬件维保商在更换电池时有没有动到其他东西，得到了很准确的回答，我们就换个电池其他啥也没用动。于是连接存储SM把A控所有LUN切到B控，系统内能看到所有盘，OK 问题在A控上面，SM中看到的存储无报错无问题，继续把原来A控的LUN切到A控中，系统又找不到了……

　　开始删除所有硬盘然后重新识别……还是不行……

　　忙来忙去 两三个小时过去了，客户在旁边一直说啥时候能搞好啊，硬件维保商的人没事似的在旁边坐着……

　　我要去机房看一下，必须看一下。客户带着我们下了机房，然后看了主机以及HBA卡连接线，一切看起来都那么美好。然后看到了存储A控出的那条光纤线……

　　你妈的插错了！！！ 客户用异样的眼光看着硬件维保商……

　　处理问题切勿先入为主，任何事要自己确定一下以免有误！！！