上周偶然与fcicq讨论到一个关于perlcc的优化问题。据说用perlcc将perl程序编译成C程序后再用gcc -O3进行优化，速度可能会快一些。于是就测了测，顺便试了试其他语言的情况。

测试程序是Ackermann函数。也许用它来做benchmark不太合适，但毕竟这是个纯数学+多次递归+耗时的运算，也能反映一定问题吧。

先来看Perl的原版。

$ cat ack.pl
#!/usr/bin/perl

sub ackermann {
  my ( $m, $n ) = @_;

  return $n + 1 if $m == 0;
  return ackermann( $m - 1, 1 ) if $n == 0;
  return ackermann( $m - 1, ackermann( $m, $n - 1 ) );
}

print ackermann( 3, 10 ), "\n";

$ time ./ack.pl
8189

real    1m5.044s
user    1m4.412s
sys     0m0.620s

结果约为65秒。然后用perlcc编译并gcc -O3优化试试：

$ cp /usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/DynaLoader/DynaLoader.a .
$ ar xv DynaLoader.a          # 先弄个必要的DynaLoader.o否则会连接错误
$ perl -c -o ack-perlcc.c ack.pl
$ gcc -O3 -c -o ack-perlcc.o `perl -MExtUtils::Embed -e ccopts` ack-perlcc.c
$ gcc -o ack-perlcc `perl -MExtUtils::Embed -e ldopts` DynaLoader.o ack-perlcc.o
$ time ./ack-perlcc
8189
real    1m3.487s
user    1m3.012s
sys     0m0.484s

用了63秒，跟perl是同一数量级的。可见这个perlcc之后没什么效果。

遗憾之余顺手写了个纯C版本：

$ cat myack.c
#include <stdio.h>

int ackermann(int m, int n);

int main() {
  int result = ackermann(3, 10);
  printf("%d\n", result);
  return 0;
}

int ackermann(int m, int n) {
  if (m == 0) return n+1;
  if (n == 0) return ackermann(m-1, 1);
  return ackermann(m-1, ackermann(m, n-1));
}

$ gcc -O3 -o myack myack.c
$ time ./myack
8189

real    0m0.231s
user    0m0.228s
sys     0m0.004s

哇！0.23秒，比perl语言快了280倍以上。看来谈到效率时果然C语言才是王道。也难怪为什么C程序员的待遇那么高了。

当然这个程序是纯粹的数学运算，发挥不出perl的长处，才会让perl效率如此低吧。

PHP也有同样的问题。还是这个Ackermann函数，用纯PHP写出来的效率很低，但如果将函数写成php extension再调用，效率几乎等同于C语言的效率。于是得出个结论，复杂的算法还是不要用PHP直接实现，而是写成extension吧。

The installation of VBox, creation of the guest and installation of Debian Etch was done in the normal fashion. Once that was completed I followed the following steps to setup networking.
//以正常方式完成VBox的安装，Guest系统的创建以及Debian的安装之后，按照以下步骤来设置网络

I. Create Network Connection in VBox
1.  Network => Settings => Open VBox
2. Click on “Attached to” and then select “Host Interfaces”;
3. In Host Interfaces click Add;
4. Type "VirtualBox Host Interface #" without the quotation marks where the # represents a number for the interface, usually 1 (on one computer the name of the virtual box host interface appeared automatically, on the other computer I had to type the information);
5. Click OK, and
6. Close VBox
// 在虚拟机中创建网络连接
1. 虚拟主机设置 -〉网络 –〉网络连接方式
2. 选择“Host Interface”
3. 在Host Interface 点击“添加”
4. 输入“VirtuakBox Host Interface #”（注：不输入引号，#号代表接口的数字，通常为1）
5. 点击OK
6. 关闭虚拟主机设置

II. Create a Network Bridge
Network Connections;?1. Open Control Panel
2. While holding down Ctrl select the Local Area connection and click on the VirtualBox Host Interface;
3. Right click on one of the selected connections; and
4. From the drop-down menu select Create Network Bridge
// II.创建一个网桥
1． 打开控制面板-〉网络连接
2． 按下“Ctrl”键的同时选择“本地连接”和“VirtualBox Host Interface”
3． 在其中一个选择的连接上，点右键
4． 从下拉菜单里选择，创建网桥

Since I am using static IP’s on my network set up I had to configure the TCP/IP properties for the Network Bridge.
//注：由于我的网络使用的是静态IP设置，因此必须配置网桥的TCP/IP属性
5. Right click on the Network Bridge that was just created;
6. Select TCP/IP;
7. Click on Properties;
8. Set the Static Connection Values; and
9. Close Network Connection.
//
5． 在刚刚创建的网桥上右击，选择属性
6． 选择TCP/IP
7． 点击属性
8． 设置静态IP地址的值
9． 关闭网络连接

III. Set Network Adapters to promiscuous mode
//III.设置网卡为混杂模式
When VBox and the guest VM load Windows XP should put the network adapters into promiscuous mode, but sometimes this does not happen. Therefore, I think it is best to force the adapters into promiscuous mode. It is only necessary to do this once.
当VBOX和VM主机载入后，XP应该自动使网卡处于混杂模式，但有时候并未实现。因此，最好手工强制网卡处于混杂模式。只需按以下步骤操作。
1. Open a Run and type "CMD" without the quotes and press?Windows command prompt (Start ENTER;
2.  Type "netsh bridge show adapter";
3. There will be a line of information displayed for each network adapter in the Bridge. Look for any adapter that is listed as disabled, note the number of the adapter and go to step four.
4.  Type "netsh bridge set adapter # forcecompatmode=enable" for each adapter that was listed as disabled, inserting the number of the adapter for the #;
5. Type "netsh bridge show adapter" once again to check to see if your adapters have been enabled;
6. Exit the command prompt; and
7.  Reboot the computer.
// 
1. 开始 –〉运行 –〉输入”CMD”
2. 输入“netsh bridge show adapter”
3. 网桥中的每张网卡会有一行信息显示。注意显示为“未应用”的每张网卡，记下网卡的数值然后看第4步
4. 输入“netsh bridge set adapter # forcecompatmode=enable”为每张显示为未应用的网卡，输入相应的网卡号，并运行一遍命令

III. Configure the TCP/IP Properties for the Debian guest
   //
     为VM客户机操作系统配置TCP/IP属性
Again, this is necessary because I am using static IP's in my LAN.
     同样，这是必须的，应为我的LAN使用静态IP
1. Open VBox;
2.  Start Debian;
3.  Since I have installed GNOME Networking;?Administration?desktop I will open    Networking by clicking Desktop
4.  Select Ethernet Connection eth0;
5.  Click on Properties;
6.  Set the static configuration for the Debian VM;
7.  Close Networking; and
8.  Reboot Debian.
//
1. 打开虚拟机
2. 启动Debian
3. 由于我安装可Gnome，我将通过桌面打开网络
4. 选择网络连接eth0
5. 点击属性
6. 设置静态IP地址
7. 关闭网络
8. 重起Debian
After Debian has rebooted LAN connections with the host and any other computers
on the network should have been established.
//
  Debian重起之后，虚拟主机与LAN里其他计算机的网络连接就建立了。

google了半天发现是xf86-input-vmmouse的新版本bug，替换 xf86-input-vmmouse 的主要驱动文件 /usr/lib/xorg/modules/input/vmmouse_drv.so 就可以了。点击下载打过补丁的 vmmouse_drv.so，下载后改名成 vmmouse_drv.so 替换上面的文件。

打开“网络连接”，在VPN连接点右键，“属性”-“网络”-“Internet协议（TCP/IP)”-“属性”-“高级”-“常规”，去掉“在远程网络上使用默认网关”的勾。

连上VPN，cmd下ipconfig /all 找出VPN连接获取的ip地址，例如是 10.200.7.254

那么，把你打算访问的远程局域网的网段全部发到这个ip吧，例如要使10.*.*.*全部走这个连接：

route  add 10.0.0.0 mask 255.0.0.0   10.200.7.254 metric 1

最后route print确认下

hacmp.棍子.灵异现象

     hacmp是IBM在P系列服务器上使用的群集管理软件，安装配置很方便，在实际使用中可处理常见的系统单点故障，从而提高整套系统的可用性。但是使用hacmp的环境常常出现一些奇怪的现象，从而让维护的技术人员头疼不已,我们称之为“灵异现象”……

     2002年的夏天，湖南长沙，XX医院，hacmp互备。

     这个医院的财务系统用的是IBM H85的双机，hacmp互备模式，DB2数据库，2台机器分管住院部和门诊部的财务系统。不知道从哪一天开始，这套系统也碰上了让人头疼的“灵异”。医院的系统管理员说他们在正常使用中发现住院部的财务系统运行突然变慢了，经检查才发现住院部那台机器已经宕机，住院部业务已经由门诊部那台顺利接管，只不过由于系统资源紧张，所以才让窗口的业务人员发现速度有异。接下来，系管重新开机，重新启动hacmp，一套流程走下来，住院部主机重新担负起了自己的任务，业务窗口速度也恢复了正常。

看上去一切都挺好，系统环境又恢复了正常，只不过……

三天以后，住院部主机又挂了。再来一次恢复流程，住院部主机起死回生……

三天以后，“挂”就一个字……

如此反复，这家医院的系管已经可以掐指算出住院部主机即将到来的“死亡时间”，误差不超过3小时。在这家医院信息部领导精神全面崩溃之前，他们找到了我所在的公司。

老板给我交代任务的时候，附带告诉我在此之前已经有资深的软硬件工程师到现场全面检查过了，每个人都是拍拍胸脯告诉可怜的系管自己这一块绝对没问题然后以尽可能快的速度离开了现场，留下系管一人绝望的面对即将到来的宕机时间……死亡无法避免。

说实话，这附带信息对当时只有一年AIX经验的我来说不是什么很有用的消息，除了凭空多出许多压力之外。

到了现场，我一直在想一个问题——系管的头发是一直这么少，还是这段时间才发生了变化。问题没有答案，我只希望自己能够帮到这个可怜的同行，看上去他虽然很热情，但是和遍访名医的重症病人家属一样，眼神中已经失去了“求生”的信念。

排除杂念，对着住院部的主机我砍出三板斧——df，errpt，diag。无效。一切看上去都很正常。细想想，这也正常，这三斧头是个人就会砍。想必在我之前来的那些资深已经都砍过三十几斧头了。再看看hacmp.out文件，顿时有了点不敢相信自己眼睛的感觉——已经生成了近50MB的文本文件。原本想从里面找点信息的想法一瞬间也去了大洋对岸。难怪资深们都闪人了，我似乎有点明白了。

口中默念着高中班主任留给我的名人名言——“人啊！不能在一棵树上吊死，让我们一起来换棵树吧！”——我杀向门诊部主机。

系管有些惊讶，但还是尽量委婉的告诉我：“严工，这台机器是好的”。

“知道”，回应：“我看看”

同样无效的三斧头过后，总算hacmp.out给了我一线希望，这台机器的hacmp.out相比较而言还算正常，虽然也过分的达到了11MB的大小。

在“尽量”仔细的阅读hacmp.out之后，我开始深刻理解资深们的难处了。巨量的事件脚本记录给“阅读”带来了麻烦，2个小时的仔细阅读之后，除了感觉眼睛有点疼，我暂时没有别的新见解。

无奈中，我开始快速翻屏，现在回想起来，当时这么做可能是潜意识中的什么元素起了作用。如《骇客帝国》中飞快滚动的黑底绿字由下至上的掠过屏幕，除了更加不可阅读之外，似乎没有别的什么好处了。

等等……这是什么……

由于快速翻屏和每个事件纪录长度大致相等的2个重要因素，加上视觉暂留效应，我在屏幕上的特定位置看到了近乎稳定的事件名称fail_standby_adapter和join_standby_adapter。这两个事件记录名称如此显眼的出现在我面前，确实让我精神为之一振。这样的情况下我还能看到这两个事件，只能说明这两个事件出现的次数特别多。详细检查了这两个事件发生的时间点，得到了让我开始感觉兴奋的消息——每秒钟要发生4到5次的fail_standby和join_standby。这说明有块standby的网卡不断的退出和加入到standby状态。顺着思路往下想，如此高频率发生的事件记录除了要写入本机的hacmp.out还要通过网络写入到另外节点的hacmp.out，这样会直接导致另外节点的hacmp.out处于持续打开的状态，同时也会占用相当大空间的file buffer且由于不断的写入而不会释放。物理实存用完之后开始使用paging，加上业务压力，paging用完之后，主机必死无疑。这样一个内存耗尽的过程，三天都算是撑得够长了。

带着激动的心情我检查了不断fail和join的standby网卡的物理位置——门诊部主机的standby网卡，这就可以解释为什么一旦住院部主机宕机，门诊部主机可以接管住院部业务除了速度慢之外而不会再宕机。因为这个接管时间点之后，原门诊部主机standby网卡已经接管了住院部主机的service地址，当然也就不存在fail_standby和join_standby的事件发生了，取而代之的是住院部业务系统的service网卡有丢包——表现出来的现象就是住院部窗口业务运行慢。

因为做过diag没有发现网卡损坏，所以问题发生的原因如果不是网线就是交换机端口。

等我告诉那个心灰意冷的人问题原因就在一根网线上时，你完全可以想象他当时的表情。而我当时脑海里出现的场景则是我父亲当年用一根木棍就修好了我母亲厂里的巨型空调并且赢得了她的芳心，他只是用棍子敲了敲那台不肯工作的机器一切就恢复了正常。多年以后，我父亲每每提起此事，总是得意地告诉我“关键不在用什么棍子，在于你要知道敲哪里”

换过一根网线，我在两台主机的hacmp.out里面没有再发现不断生成的事件记录，此刻对我来说，问题已经解决了。而忐忑不安的系管估计要等到下次“死亡时间”之后才能放下心来了。

回顾整个过程，实际上hacmp的事件记录文件hacmp.out已经清晰而忠实地记录了发生过的点点滴滴，如果你有足够的耐心和方法，你肯定可以从中找到答案，肯定可以从中知道你手中的棍子要敲向哪里。仔细“阅读”记录文件，会使我们的PD过程更加顺利。而且，你千万不要认为看似正常运行的设备一定没有任何问题。

离开现场，带着我的“棍子”，开心……

微码.警察.跑路

     在做AIX service的这段日子里，我有个深刻的体会——“开始因为什么都不会，所以胆小，慢慢的，知道了一些，胆子也变得大了起来，其必然会导致出现一些大家都不想看到的结果，多经历几次这样的事情，胆子会慢慢的再度变小”。下面的故事就发生在我胆子好大的时候！

      2003年的春天，湖北武汉，市公安局，S70双机。

      武汉市公安局信息科，S70双机，一台是运行户政管理业务，一台是公安内部信息平台系统。因为这2台S70买的时间比较早，所以配置相对不高，在业务运行高峰期，常常会让各个运行终端的干警们心生郁闷。

为了更好的迎接第XX次人口普查，市局的领导们特意指示信息科要做好细致的准备工作，不要发生意外拖前线干警的后腿。于是信息科领导将指令转化成了一次S70间的配置调整——即暂停公安系统内部消息平台的运行，将消息平台主机上的内存全部转移到户政管理主机上，以尽可能好的配置来迎接第XX次人口普查的到来。
    任务交到我身上，在我这里则转化成了具体的实施步骤“停机-拆内存-加内存-开机”，看起来是件简单任务。至少，除了会浑身是灰之外，我没想到还有什么麻烦事情会发生。

事实证明，通常胆大的人不一定会有好运气。

确认过业务系统都已经关闭的情况下，我开始停机步骤，shutdown –F之后信息平台主机乖乖的回到了OK状态。但是户政管理平台主机则迟迟没有出现halt complete的字样。虽然觉得有什么地方有点不对劲，但在长达10分钟的等待之后，我还是直接关闭了这台户政管理S70主机的电源。

30分钟后，内存物理更换完成，依照service guide的指引我将新加入的内存放在了他们应该在的位置。

加电，开机，LCD上绿色的小字符开始快乐的跳动起来……

只是，跳到了XXXX代码之后，LCD好像停止了动静，连OK字符都没有出现，LCD就停止了跳动。

5分钟之后，状态依然，我开始查service guide，看看这串代码到底是什么含义。结果让人晕厥——service guide上没有这串字母的对应描述，前后的字母串描述都有，唯独少了这一串的解释。

脑袋一片混乱的我开始联想，机器起不来——户政管理业务起不来——全市派出所户籍民警无法工作——全市人民不能上户口，不能结婚，哪怕连死亡消户口都不可以……

说实话，那一瞬间我跑路的心都有了……

定定神，打出场外求助电话，电话打给的是IBM华中区的资深工程师吴炬，简短的交流之后，从他那里我得到了一个意外的答案——他告诉了我sevice guide中对这段字母含义的描述，可是，可是我明明看过service guide了呀！并没有看到这串字母描述啊！在核对过书号和文件大小之后，我得到了当天的第一个重要感受——针对每种机型的service guide经常会有更新，所以会有很多的版本，保持经常下载最新版本的service guide绝对是个好习惯。

回到现场，这串字母的含义是系统微码损坏，需要用软盘重新刷新微码。

接下来的时间是在公司（下微码，做升级软盘）和市局之间飞奔度过的……

刷完系统微码，果然OK字符重现，再世为人了……

系统顺利起来之后我才发现，原来errpt里面已经记录了183天之前微码发生错误的记录，也就是说不管是谁，只要关了机器，那么除非刷新系统微码，否则就是局长来了机器也会无法启动，只不过这次我是在微码损坏后第一个关机的幸运儿。这让我得到了当天的第二个重要感受——设备总是有可能出现问题的，哪怕关机之前看上去一切正常，所以在有任何动作之前，仔细检查errpt总归是没有坏处的。如果有可能，关机之后马上启动一次是确保设备处于正常状态的最好办法。

出了市局，我突然发现不用跑路，可以回家的感觉真好……

Oracle.球.世界杯

四年一次的世界杯在2006年的夏天如约而至，在和平的年代，这几乎就是世界大战的代名词，由于中国队的一贯表现，我不太关注这块没有硝烟的战场。当然，几场枭雄之间的对决还是要亲眼目睹的。那个早晨，带着五星巴西竟然负于法国的疑问我沉沉睡去，一个小时后，我被VIP客户电醒……

2006年的夏天，上海，中国XX银行数据中心，P590

在早上6点接到VIP客户的电话通常意味着有地方“失火”了，在没有了解情况之前我只是希望“火”不要烧得太大，但眼看我这次的衷心希望显然没有半分效果……

这家VIP客户的一台满配置P590承载着该行全国法人信贷的业务系统，在这个对于巴西人来说显然比较黑暗的早晨居然宕机了，我一边念叨着“你跟巴西应该没什么关系吧？兄弟！”一边晕乎乎的冲向VIP。

“火”确实烧得有点大——系统重启后，技术人员发现oracle没法启动，经检查发现oracle的code所在的目录没有mount上来，手工mount后系统提示文件系统有问题，需要做fsck。而fsck之后则是一喜接着一惊——喜的是该文件系统可以mount了，惊的是system.dbf和user.dbf消失了。O_Ob

OK，让我们切到备机好了，恢复业务系统online是这个时候第一目标……

二惊——用data guard保持数据同步的备机在头一天已经切断了数据同步状态……

那么，让我们用磁带里的备份来恢复数据吧！该是那个小屋子大小的磁带库发挥作用的时候了……

三惊——该数据库resetlogs在头一天的凌晨已经被重置了，而重置之后没有重新做全备……

我已经开始考虑是不是有人急于下岗而没有足够的勇气提出来，想通过这样的事件来促成自己的心愿。

之后的恢复步骤这里不再赘述，训练有素的X行技术人员启动应急预案，在最短的时间内恢复了这套涉及全国范围的法人信贷系统，只让遍及全国的相关工作人员稍微休息了半天而已。

而我面临的问题则是要搞清楚是什么原因导致这台P590在明显和巴西没什么关系的情况下，会如此冲动的通过宕机来表达自己的情绪。

形势似乎对我们不利，系统宕机——文件系统损坏——修复之后重要文件丢失……

当年的三斧头现在已经升级成了snap，PFE，PSDB。挥舞完这三斧头，我得到的信息是这个文件系统在宕机前30小时已经出现了错误的文件控制数据，并且通过errpt提醒用户需要做fsck进行检查，只不过可惜的是无人理会。同时，二线技术支持人员告知我系统宕机的原因是AIX在对此文件系统B+树扫描时，发现此文件系统不一致信息过多，而采取的自动重启，从而在umount的状态下对其进行自动fsck。这一点我也在alog里面得到了验证。

问题已经转变成了文件系统为什么会损坏了？

询问过X行相关技术人员之后，我得到了重要的信息——宕机前32小时，此应用系统由于undo扩展过快，所以DBA打开了undo的autoextend参数。而undo文件正好就放在和system.dbf、user.dbf同一个目录中。参数修改了1个多小时之后，oracle突然crash了，oracle的工程师到现场进行的恢复动作，在修复之后出于某种原因的考虑断开了data guard的数据同步链。

带着这些重要信息，我在三方会议（X行，我们，oracle）召开的头一天夜里潜入“敌营”——metalink，一边翻腾一边庆幸自己还拥有metalink的账号……

会议正式开始之前，我已是胸中有伏兵了，虽不敢有完胜的奢望，但已然不是之前的心中暗自理亏的状态。在和team中的成员share了“敌营”中的收获之后，我特意的询问了leader关于这些杀手锏的使用时机问题。他告诉我的原则简单明了——“看看oracle的态度再说。”

会议开始，oracle代表慢条斯理的扔出了一句话“oracle认为，既然是操作系统发生文件系统损坏、无故宕机，同时丢失了重要的数据文件，那么问题的责任应该在操作系统这里，如何检查、修复也请操作系统这边着手进行。”

当时我的脑袋里马上回想起了周星星的那句“兄弟！球，不是这样踢滴！”

虽然事实上我并不喜欢踢球，但是更加不喜欢人家把球踢到我们球门口。

“首先，问题的起因在于undo文件被设置成了autoextend，但是并没有设置maxsize,同时自动扩展的步进参数next被设置成1MB。而max_tetention参数还是默认的1080也就是3小时。从修改参数到文件系统被撑满只用了1小时20分，undo文件扩展了22GB。而在9i里面把undo设置成autoextend但并不设置maxsize，undo会一直增长而不重用过期的回滚段，这是个地球人都知道的bug，undo文件所在的目录被撑爆只是个时间问题而已”

我先扔出了在敌营中的第一个发现，立马发现oracle工程师表情明显变得有些呆滞。接着乘胜追击……

“其次，让我们来看看undo文件在这么短的时间内扩展了22GB是否正常？在metalink里，我找到了5个与undo文件在某些特定情况下会产生非正常的巨量增长的相关补丁，由于我metalink账号的权限不够高，有些未公布的补丁我还看不到，所以我并不确定能够修正undo文件产生巨量增长的补丁只有5个。”

已经发现刚才还慢条斯理的那人脸色有些发白，好，我们继续……

“第三，在宕机前30小时，操作系统已经发现这个被撑爆的文件系统出现了错误的文件系统控制数据，同时建议马上做fsck修复。当时因为undo被撑爆，所以oracle crash了。在调整undo的文件位置的过程中，oracle重新成功启动关闭过多次，这个时间点的system.dbf和user.dbf还是完好而且可以访问的，否则oracle当时就无法正常启动instance了。但是很遗憾的是当时在场的oracle工程师没有注意到alert.log中间的提示，所以没做任何处理或者建议。”

不再观察他的表情了，已经不忍心看下去了，直接带球到对方禁区好了……

“最重要的一点是，我们不理解为什么在oracle crash的应急处理完成之后会因故断开data guard的数据同步链，这样直接导致备份系统由于缺少一天的数据，无法立刻online。而且，主系统的resetlogs也被重置，使从磁带恢复丢失的文件也成为了不可能完成的任务”

带球入禁区加上射门，一气呵成……

这场球赛已经没有悬念了……

三方会议后，为分析此次“灾情”的原因和改进建议方案，我提交了一份五千字的报告，鉴于是属于公司密级的文档，这里就不提供了，不然这“AIX与我”的故事就要破万字了。

回顾整个过程，给我最深的感受是想做好AIX的service，就不能够只熟悉AIX，与其相关的方方面面最好都能有所涉及，一个全面的中场球员需要的是能攻能守，更重要的是全局观。

马上就要进入AIX与我的第六个年头了，回顾这段历程，AIX让我学会了耐心、让我体会了关注细节的重要、让我感受到了完美schedule的强大效力。以至于我希望如果有一天真的不幸蒙冤进了fox river这样的牢狱，但愿监狱管理系统用的是IBM P系列，这样我或许还能有逃出来的一线生机……

 全文完.

一. 前言

shell编程在unix/linux世界中使用得非常广泛，熟练掌握shell编程也是成为一名优秀的unix/linux开发者和系统管理员的必经之路。脚本调试的主要工作就是发现引发脚本错误的原因以及在脚本源代码中定位发生错误的行，常用的手段包括分析输出的错误信息，通过在脚本中加入调试语句，输出调试信息来辅助诊断错误，利用调试工具等。但与其它高级语言相比，shell解释器缺乏相应的调试机制和调试工具的支持，其输出的错误信息又往往很不明确，初学者在调试脚本时，除了知道用echo语句输出一些信息外，别无它法，而仅仅依赖于大量的加入echo语句来诊断错误，确实令人不胜其繁，故常见初学者抱怨shell脚本太难调试了。本文将系统地介绍一些重要的shell脚本调试技术，希望能对shell的初学者有所裨益。

本文的目标读者是unix/linux环境下的开发人员，测试人员和系统管理员，要求读者具有基本的shell编程知识。本文所使用范例在Bash3.1 +Redhat Enterprise Server 4.0下测试通过，但所述调试技巧应也同样适用于其它shell。

二. 在shell脚本中输出调试信息

通过在程序中加入调试语句把一些关键地方或出错的地方的相关信息显示出来是最常见的调试手段。Shell程序员通常使用echo(ksh程序员常使用 print)语句输出信息，但仅仅依赖echo语句的输出跟踪信息很麻烦，调试阶段在脚本中加入的大量的echo语句在产品交付时还得再费力一一删除。针对这个问题，本节主要介绍一些如何方便有效的输出调试信息的方法。

1. 使用trap命令

trap命令用于捕获指定的信号并执行预定义的命令。
其基本的语法是:
trap 'command' signal
其中signal是要捕获的信号，command是捕获到指定的信号之后，所要执行的命令。可以用kill –l命令看到系统中全部可用的信号名，捕获信号后所执行的命令可以是任何一条或多条合法的shell语句，也可以是一个函数名。
shell脚本在执行时，会产生三个所谓的“伪信号”，(之所以称之为“伪信号”是因为这三个信号是由shell产生的，而其它的信号是由操作系统产生的)，通过使用trap命令捕获这三个“伪信号”并输出相关信息对调试非常有帮助。

表 1. shell伪信号

通过捕获EXIT信号,我们可以在shell脚本中止执行或从函数中退出时，输出某些想要跟踪的变量的值，并由此来判断脚本的执行状态以及出错原因,其使用方法是：
trap 'command' EXIT　或　trap 'command' 0

通过捕获ERR信号,我们可以方便的追踪执行不成功的命令或函数，并输出相关的调试信息，以下是一个捕获ERR信号的示例程序，其中的$LINENO是一个shell的内置变量，代表shell脚本的当前行号。

其输出结果如下：

在调试过程中，为了跟踪某些变量的值，我们常常需要在shell脚本的许多地方插入相同的echo语句来打印相关变量的值，这种做法显得烦琐而笨拙。而通过捕获DEBUG信号，我们只需要一条trap语句就可以完成对相关变量的全程跟踪。

以下是一个通过捕获DEBUG信号来跟踪变量的示例程序:

其输出结果如下：

从运行结果中可以清晰的看到每执行一条命令之后，相关变量的值的变化。同时，从运行结果中打印出来的行号来分析，可以看到整个脚本的执行轨迹，能够判断出哪些条件分支执行了，哪些条件分支没有执行。

2. 使用tee命令

在shell脚本中管道以及输入输出重定向使用得非常多，在管道的作用下，一些命令的执行结果直接成为了下一条命令的输入。如果我们发现由管道连接起来的一批命令的执行结果并非如预期的那样，就需要逐步检查各条命令的执行结果来判断问题出在哪儿，但因为使用了管道，这些中间结果并不会显示在屏幕上，给调试带来了困难，此时我们就可以借助于tee命令了。

tee命令会从标准输入读取数据，将其内容输出到标准输出设备,同时又可将内容保存成文件。例如有如下的脚本片段，其作用是获取本机的ip地址：

运行这个脚本，实际输出的却不是本机的ip地址，而是广播地址,这时我们可以借助tee命令，输出某些中间结果，将上述脚本片段修改为：

之后，将这段脚本再执行一遍，然后查看temp.txt文件的内容：

我们可以发现中间结果的第二列(列之间以:号分隔)才包含了IP地址，而在上面的脚本中使用cut命令截取了第三列，故我们只需将脚本中的cut -d : -f3改为cut -d : -f2即可得到正确的结果。

具体到上述的script例子，我们也许并不需要tee命令的帮助，比如我们可以分段执行由管道连接起来的各条命令并查看各命令的输出结果来诊断错误，但在一些复杂的shell脚本中，这些由管道连接起来的命令可能又依赖于脚本中定义的一些其它变量，这时我们想要在提示符下来分段运行各条命令就会非常麻烦了，简单地在管道之间插入一条tee命令来查看中间结果会更方便一些。

3. 使用"调试钩子"

在C语言程序中，我们经常使用DEBUG宏来控制是否要输出调试信息，在shell脚本中我们同样可以使用这样的机制，如下列代码所示：

这样的代码块通常称之为“调试钩子”或 “调试块”。在调试钩子内部可以输出任何您想输出的调试信息，使用调试钩子的好处是它是可以通过DEBUG变量来控制的，在脚本的开发调试阶段，可以先执行export DEBUG=true命令打开调试钩子，使其输出调试信息，而在把脚本交付使用时，也无需再费事把脚本中的调试语句一一删除。

如果在每一处需要输出调试信息的地方均使用if语句来判断DEBUG变量的值，还是显得比较繁琐，通过定义一个DEBUG函数可以使植入调试钩子的过程更简洁方便，如下面代码所示:

$ cat –n exp3.sh
     1  DEBUG()
     2  {
     3  if [ "$DEBUG" = "true" ]; then
     4      $@　　
     5  fi
     6  }
     7  a=1
     8  DEBUG echo "a=$a"
     9  if [ "$a" -eq 1 ]
    10  then
    11       b=2
    12  else
    13       b=1
    14  fi
    15  DEBUG echo "b=$b"
    16  c=3
    17  DEBUG echo "c=$c"

在上面所示的DEBUG函数中，会执行任何传给它的命令，并且这个执行过程是可以通过DEBUG变量的值来控制的，我们可以把所有跟调试有关的命令都作为DEBUG函数的参数来调用，非常的方便。


三. 使用shell的执行选项

上一节所述的调试手段是通过修改shell脚本的源代码，令其输出相关的调试信息来定位错误的，那有没有不修改源代码来调试shell脚本的方法呢？答案就是使用shell的执行选项，本节将介绍一些常用选项的用法：

-n 只读取shell脚本，但不实际执行
-x 进入跟踪方式，显示所执行的每一条命令
-c "string" 从strings中读取命令

“- n”可用于测试shell脚本是否存在语法错误，但不会实际执行命令。在shell脚本编写完成之后，实际执行之前，首先使用“-n”选项来测试脚本是否存在语法错误是一个很好的习惯。因为某些shell脚本在执行时会对系统环境产生影响，比如生成或移动文件等，如果在实际执行才发现语法错误，您不得不手工做一些系统环境的恢复工作才能继续测试这个脚本。

“-c”选项使shell解释器从一个字符串中而不是从一个文件中读取并执行shell命令。当需要临时测试一小段脚本的执行结果时，可以使用这个选项，如下所示：
sh -c 'a=1;b=2;let c=$a+$b;echo "c=$c"'

"-x"选项可用来跟踪脚本的执行，是调试shell脚本的强有力工具。“-x”选项使shell在执行脚本的过程中把它实际执行的每一个命令行显示出来，并且在行首显示一个"+"号。 "+"号后面显示的是经过了变量替换之后的命令行的内容，有助于分析实际执行的是什么命令。 “-x”选项使用起来简单方便，可以轻松对付大多数的shell调试任务,应把其当作首选的调试手段。

如果把本文前面所述的trap ‘command’ DEBUG机制与“-x”选项结合起来，我们就可以既输出实际执行的每一条命令，又逐行跟踪相关变量的值，对调试相当有帮助。

仍以前面所述的exp2.sh为例，现在加上“-x”选项来执行它：

在上面的结果中，前面有“+”号的行是shell脚本实际执行的命令，前面有“++”号的行是执行trap机制中指定的命令，其它的行则是输出信息。

shell的执行选项除了可以在启动shell时指定外，亦可在脚本中用set命令来指定。 "set -参数"表示启用某选项，"set +参数"表示关闭某选项。有时候我们并不需要在启动时用"-x"选项来跟踪所有的命令行，这时我们可以在脚本中使用set命令，如以下脚本片段所示：

set命令同样可以使用上一节中介绍的调试钩子—DEBUG函数来调用，这样可以避免脚本交付使用时删除这些调试语句的麻烦，如以下脚本片段所示：

四. 对"-x"选项的增强

"-x"执行选项是目前最常用的跟踪和调试shell脚本的手段，但其输出的调试信息仅限于进行变量替换之后的每一条实际执行的命令以及行首的一个"+" 号提示符，居然连行号这样的重要信息都没有，对于复杂的shell脚本的调试来说，还是非常的不方便。幸运的是，我们可以巧妙地利用shell内置的一些环境变量来增强"-x"选项的输出信息，下面先介绍几个shell内置的环境变量：

$LINENO
代表shell脚本的当前行号，类似于C语言中的内置宏__LINE__

$FUNCNAME
函数的名字，类似于C语言中的内置宏__func__,但宏__func__ 只能代表当前所在的函数名，而$FUNCNAME的功能更强大，它是一个数组变量，其中包含了整个调用链上所有的函数的名字，故变量${FUNCNAME [0]}代表shell脚本当前正在执行的函数的名字，而变量${FUNCNAME[1]}则代表调用函数${FUNCNAME[0]}的函数的名字，余者可以依此类推。

$PS4
主提示符变量$PS1和第二级提示符变量$PS2比较常见，但很少有人注意到第四级提示符变量$PS4的作用。我们知道使用“-x”执行选项将会显示 shell脚本中每一条实际执行过的命令，而$PS4的值将被显示在“-x”选项输出的每一条命令的前面。在Bash Shell中，缺省的$PS4的值是"+"号。(现在知道为什么使用"-x"选项时，输出的命令前面有一个"+"号了吧？)。

利用$PS4这一特性，通过使用一些内置变量来重定义$PS4的值，我们就可以增强"-x"选项的输出信息。例如先执行export PS4='+{$LINENO:${FUNCNAME[0]}} ', 然后再使用“-x”选项来执行脚本，就能在每一条实际执行的命令前面显示其行号以及所属的函数名。

以下是一个存在bug的shell脚本的示例，本文将用此脚本来示范如何用“-n”以及增强的“-x”执行选项来调试shell脚本。这个脚本中定义了一个函数isRoot(),用于判断当前用户是不是root用户，如果不是，则中止脚本的执行

首先执行sh –n exp4.sh来进行语法检查，输出如下：

发现了一个语法错误，通过仔细检查第6行前后的命令，我们发现是第4行的if语句缺少then关键字引起的(写惯了C程序的人很容易犯这个错误)。我们可以把第4行修改为if [ "$UID" -ne 0 ]; then来修正这个错误。再次运行sh –n exp4.sh来进行语法检查，没有再报告错误。接下来就可以实际执行这个脚本了，执行结果如下：

尽管脚本没有语法错误了，在执行时却又报告了错误。错误信息还非常奇怪“[1: command not found”。现在我们可以试试定制$PS4的值，并使用“-x”选项来跟踪：

从输出结果中，我们可以看到脚本实际被执行的语句，该语句的行号以及所属的函数名也被打印出来，从中可以清楚的分析出脚本的执行轨迹以及所调用的函数的内部执行情况。由于执行时是第11行报错，这是一个if语句，我们对比分析一下同为if语句的第4行的跟踪结果：

可知由于第11行的[号后面缺少了一个空格，导致[号与紧挨它的变量$?的值1被shell解释器看作了一个整体，并试着把这个整体视为一个命令来执行，故有“[1: command not found”这样的错误提示。只需在[号后面插入一个空格就一切正常了。

shell中还有其它一些对调试有帮助的内置变量，比如在Bash Shell中还有BASH_SOURCE, BASH_SUBSHELL等一批对调试有帮助的内置变量，您可以通过man sh或man bash来查看，然后根据您的调试目的,使用这些内置变量来定制$PS4，从而达到增强“-x”选项的输出信息的目的。

五. 总结

现在让我们来总结一下调试shell脚本的过程：
首先使用“-n”选项检查语法错误，然后使用“-x”选项跟踪脚本的执行，使用“-x”选项之前，别忘了先定制PS4变量的值来增强“-x”选项的输出信息，至少应该令其输出行号信息(先执行export PS4='+[$LINENO]'，更一劳永逸的办法是将这条语句加到您用户主目录的.bash_profile文件中去)，这将使你的调试之旅更轻松。也可以利用trap,调试钩子等手段输出关键调试信息，快速缩小排查错误的范围，并在脚本中使用“set -x”及“set +x”对某些代码块进行重点跟踪。这样多种手段齐下，相信您已经可以比较轻松地抓出您的shell脚本中的臭虫了。如果您的脚本足够复杂，还需要更强的调试能力，可以使用shell调试器bashdb，这是一个类似于GDB的调试工具，可以完成对shell脚本的断点设置，单步执行，变量观察等许多功能，使用bashdb对阅读和理解复杂的shell脚本也会大有裨益。关于bashdb的安装和使用，不属于本文范围，您可参阅http: //bashdb.sourceforge.net/上的文档并下载试用。


参考资料

    * 请访问： GNU 的 bash 主页

    * 请下载和试用 Shell调试器bashdb



关于作者

               

曹羽中，在北京航空航天大学获得计算机软件与理论专业的硕士学位，具有数年的unix环境下的C语言,Java,数据库以及电信计费软件的开发经验，他的技术兴趣还包括OSGi和搜索技术。他目前在IBM中国系统与科技实验室从事系统管理软件的开发工作,可以通过 caoyuz@cn.ibm.com与他联系。

事件类型: 错误
事件来源: DCOM
事件种类: 无
事件 ID: 10020
日期:  2007-12-1
事件:  12:23:39
用户:  N/A
计算机: RENZHE
描述:
整个计算机的 默认值 启动和激活 安全描述符无效。它包含的带权限的访问控制项无效。因此没有执行请求的操作。可以使用组件服务管理工具更正此安全权限。

有关更多信息，请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。

解决方法：

控制面板 - 管理工具 - 组件服务 - 组件服务 - 计算机 - 我的电脑 - 右键“属性”- 切换到“COM安全”标签页 - 点“启动和激活权限”下的“编辑默认值”，把WebSphere自动添加的mqm、MUSR_MQADMIN用户添加进去就ok了。

关于DCOM的ID为10020的错误应该都是类似的处理方法，一般都是软件自动创建的用户的权限问题。

PS:发现自己最近上班时看日志看傻掉了，xp的日志都这么关心...

事件类型: 警告
事件来源: Userenv
事件种类: 无
事件 ID: 1517
日期:  2007-11-19
事件:  4:11:04
用户:  NT AUTHORITY\SYSTEM
计算机: RENZHE
描述:
Windows 保存了用户 RENZHE\忍者 的注册表，因为在注销时一个应用程序或服务还在使用此注册表。用户注册表使用的内存没有被释放。当不再使用注册表时，它将被卸载。

 这通常是因为服务按用户的帐户运行。请尝试配置服务用本地服务或网络服务帐户运行。

有关更多信息，请参阅在 http://go.microsoft.com/fwlink/events.asp 的帮助和支持中心。

看着不爽，找了半天发现微软提供的所谓正版增值工具可以把这个告警弄掉，免激活版本的xp-sp2加个好的序列号应该能通过这个正版验证：

http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=1b286e6d-8912-4e18-b570-42470e2f3582

As you all probably know by now Sun decided to sell Windows 2003 servers (gasp, sputter… Scott McNealy would surely turn in his grave on hearing this news; wait a minute, he is still the Chairman of Sun) on its hardware. The key question on everyone’s mind is has Sun finally found a direction as Microsoft’s partner or has Sun joined the dark side as some would like to say or has Sun finally lost its marbles or whether it is really a strategically brilliant move? Significantly Jonathan Schwartz, CEO of Sun Microsystems, is eerily silent on his blog about this initiative and continues to promote OpenOffice as an alternative to Microsoft Office.

Excerpt from Press Release

Sun and Microsoft will work together to ensure that Solaris runs well as a guest on Microsoft virtualization technologies and that Windows Server runs well as a guest in Sun’s virtualization technologies.

Sun and Microsoft will continue to collaborate to advance the worldwide deployment of the Microsoft Mediaroom IPTV and multimedia platform on Sun server and storage systems.

Microsoft and Sun will build an Interoperability Center on Microsoft’s Redmond campus. The center will include a demonstration area for Sun x64 systems, act as a working lab for Windows on Sun benchmarks and sales tools, and support customers running proofs of concept for projects focused on Windows on Sun x64 systems, including joint Sun/Microsoft solutions in areas such as databases, e-mail and messaging, virtualization, and Remote Desktop Protocol (RDP) support in Sun Ray thin clients.

Sun’s Strategy or lack of it…

Sun’s strategy by ArsTechnica

In its early days McNealy adopted a strong anti-Microsoft position primarily as a marketing tactics and continued it over the years. I really doubt that it helped Sun in any way.
Sun did however undertake several initiatives over the years to undermine Microsoft of which only Java succeeded and Star Office / Open Office to some extent.

Java Desktop is one of the many initiatives where Sun couldn’t make much headway. In the process Sun ended up open sourcing Solaris & Java, both of which, especially Solaris, I think are strategic blunders.

Solaris (and many would say the original Sun OS) was the life blood of Sun for many years. Sun OS & Solaris on Sun hardware is what gave Sun strategic advantage in the middleware market. While Sun lost its ground in recent years, I would attribute it more to lack of comparative CPU performance improvement (wrt. Intel chips) than to Solaris. Solaris remains to this day the leading stable production ready operating system.

Sun should have moved over to using Intel chips much earlier. Steve Jobs made a wise decision to move over to Intel chips and so should have Sun. Moving over to Intel (not Wintel) would have allowed Sun to keep its competitive advantage. Instead Sun at one point decided to even downgrade importance of supporting Solaris on Intel chips.

Several of recent Sun’s initiatives leads me to think that Sun is not following a unified strategic vision in the last 4-5 years. Most of Sun’s initiatives appears to be fishing expeditions, unguided by a vision or sense of purpose. Sun reminds me of our Defence Research Development Organization (DRDO) which is spending our military fund on agriculture; and prides itself on finding the hottest chilli.

Logically the only option that Sun has moving forward is jumping 100% into the services bandwagon and start competing with the likes of IBM & Infosys.

Sun Preparing for Microsoft Takeover?

If I were to speculate, I wouldn’t rule-out a takeover of Sun by Microsoft. First a 2 billion dollar dole and now Microsoft has Sun as its Windows 2003 server vendor, Microsoft definitely has Sun by the short hairs.