这两天一直被下面的错误所困扰：
AP13: lb -m ccmscell uptime ld.so.1: uname: fatal: /usr/lib/secure/0@0.so.1: open failed: No such file or directory ksh[216]: 4412 Killed ld.so.1: uptime: fatal: /usr/lib/secure/0@0.so.1: open failed: No such file or directory
lb是一个调用rsh的脚本，ccmscell是一个server pool，uname是在lb中被调用的。
仔细研究了N遍相关的脚本，Google了N次相关的错误信息，都没有找到有价值的线索。后来问了一位做过IT的同事，她说以前遇见过类似的问题，可她的解决方案最终被证明无效。
最终发现不是所有的server上执行这条命令都有问题，有些是可以执行的。对比了之后发现，如果/usr/lib/secure/0@0.so.1的group设置为bin，owner设为root，就不会出现上面的问题。出问题的server上/usr/lib/secure/0@0.so.1的group为other。
进一步调查后发现，/usr/lib/secure/0@0.so.1是在Solaris 5.8上被设为LD_PRELOAD_32的，因为很多程序要被setuid+chroot的伪root调用。当且仅当上面的命令被该伪root执行时，才会出现上面的错误！
幸亏Solaris 5.8已经开始走进坟墓了，即使在落后如我们公司的地方！
【update2011-06-23】：
今天发现root cause 不是由于/usr/lib/secure/0@0.so.1的group不对，而是因为remote server（比如pool ccmscell中的server）上没有/usr/lib/secure/0@0.so.1 —— 执行rsh命令的login是setuid+chroot实现的伪root，因此远程的server就需要/usr/lib/secure/0@0.so.1了。
【update 2012-03-12】
今天在Solaris 9上遇到了这样一个错误：
ld.so.1: pt_chmod: warning: /lib/0@0.so.1: open failed: illegal insecure pathname
查了很久才想起来有可能是/usr/lib/secure/0@0.so.1造成的。一检查/usr/lib/secure/0@0.so.1，果然不存在。
在一个正常工作的server上，
AP31: echo $LD_PRELOAD_32 /usr/lib/secure/0@0.so.1
在不能工作的server上，
AP13: echo $LD_PRELOAD_32 /lib/0@0.so.1
——仅仅升级了一个软件就又把这个library搞丢了，某些同志们啊，唉……