一個拷貝操作導致的潛在監聽類問題

最近為了統計一些伺服器的監聽使用情況，於是寫了一個簡單的指令碼，在中控中執行，指令碼邏輯很簡單，也沒有什麼亮點。
指令碼內容如下：
#check $1 is IP
base_dir=`pwd`
ssh $1 "ps -ef|grep smon|grep -v grep; ps -ef|grep tns|grep -v grep|grep -v netns" > $base_dir/tmp_checkdb.lst
echo '***DB instance as below***'
echo .
cat $base_dir/tmp_checkdb.lst|grep smon|grep -v grep|awk -Fsmon_ '{print $2}'
echo .
echo '***DB instance as below***'
echo .
cat $base_dir/tmp_checkdb.lst|grep tns|grep -v grep|awk -Ftnslsnr '{print $2}'|sed 's/-inherit//g'
指令碼的執行情況如下：
# sh checkdb.sh  10.127.133.xxx
***DB instance as below***
.
testdb
.
***DB instance as below***
.
 listener_1532
 listener_1523
 listener_testdb_1525
 listener_testdb_1528
 listener_testdb_1529
 listener_testdb_1539
 listener_testdb_1535
 listener_1521
 listener_1522
看到這個結果能夠基本得到一個整體的服務概況，這臺伺服器上有哪幾個例項（包括ASM）,對應的監聽埠有哪些，目前根據基本的規範，監聽器後是帶著相應的埠。
但是我看到某一臺伺服器的時候，突然發現了一個很奇怪的結果：
裡面有一行的結果如下:
listener_1532 lsnrctl start listener_1522
看到這個結果著實讓我有些摸不著頭腦了，到底是我解析的問題還是本身的監聽的問題，檢視細節的資訊。
系統級看到的程式情況如下：
$ ps -ef|grep tns
root        125      2  0 Apr26 ?        00:00:00 [netns]
oracle    15416  14816  0 16:26 pts/0    00:00:00 grep tns
oracle    56123      1  0 Jul14 ?        00:00:05 /U01/app/oracle/product/11.2.0.4/bin/tnslsnr listener_1532 lsnrctl start listener_1522 -inherit
oracle    56126      1  0 Jul14 ?        00:00:23 /U01/app/oracle/product/11.2.0.4/bin/tnslsnr listener_1522 -inherit
oracle    56131      1  0 Jul14 ?        00:00:23 /U01/app/oracle/product/11.2.0.4/bin/tnslsnr listener_testdb_1525 -inherit
。。。
可以看到這個監聽確實夠奇怪的，顯示是1532，同時後面還跟了1522的埠，到底是開啟了哪個埠呢。看到還有一個監聽器是listener_1522,可以基本判斷出1522是已經開通的，所以這個場景下開通的是1532埠。
因為這是一個線上業務系統，所以趕緊檢視了一下當時的後臺連線情況，沒有發現什麼異常，但是這種情況看起來非常彆扭，就想好好糾正過來，簡單評估了一下，發現這個埠的連線目前都是有一定的時間頻度，使用lsnrctl檢視監聽器的狀態，發現也沒有問題，不過為了穩妥起見，還是考慮要把這個問題矯正過來。所以打算使用最快的方式，Kill -9殺掉這個監聽的程式，然後迅速開啟這個1532的監聽器，評估之後就這麼操作了，沒有任何異常，而殺掉監聽器對於原來的連線來說也沒有什麼影響，所以很快就搞定了這個問題，但是這個問題留給我的疑問是，怎麼會出現這種情況呢，我決定復現一下這個問題，在測試之後發現原來這是一個潛在的操作問題。
lsnrctl start後面是跟一個監聽器名，相應的監聽器埠就可以成功開啟，這個場景的問題略有不同，其實是執行了這樣的操作：
 lsnrctl start LISTENER_1522 lsnrctl start listener_1521
這樣一來，我們可以看出，原來lsnrctl沒有校驗後面的幾個引數，簡直就是無視了那些引數，這個做得確實不大合理啊。而這個問題的出現其實在從文字拷貝命令的時候如果拷貝不當，很容易出現這種序列的情況，也對我們手工操作敲響了警鐘。這些看起來影響不大的細節很重要，稍有不慎就會影響大局，細節決定成敗，就是這個道理。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2122470/，如需轉載，請註明出處，否則將追究法律責任。