這兩天遇上了一個(gè)問題,可惜解決晚了,導(dǎo)致場(chǎng)景服務(wù)器的一個(gè)未知隱患要留到下次外部測(cè)試才能查出來了.
一個(gè)通過ssh連接啟停指定服務(wù)器程序的管理程序,其中一組啟動(dòng)的程序發(fā)生崩潰后無法dumpcore文件,但是改用手動(dòng)啟動(dòng)的方式程序則會(huì)在崩潰后dumpcore.
在shell環(huán)境下檢測(cè)core文件大小設(shè)置:
$ulimit -c
unlimited
讓管理程序讀取core文件大小設(shè)置:
o = machine.StartApp('ulimit -c');
print(o.readline());
$python test.py
0
設(shè)置值是0,不是預(yù)期的.但是在終端看到的卻是unlimited.其中ulimit -c的初始設(shè)置是寫在.bash_profile里的.
很幸運(yùn)的看到.bashrc里提到2種類型的shells:login shell,interactive shell.其中l(wèi)ogin shell加載.bash_profile,interactive shell加載.bashrc.
管理程序連接到機(jī)器后,沒有使用tty或者bash,因?yàn)椴恍枰换?同時(shí),管理程序執(zhí)行命令的方式是bash -c,所以管理程序沒有執(zhí)行.bash_profile中的設(shè)置,以致于子進(jìn)程繼承的core文件大小設(shè)置不符合期望.
其中的一個(gè)解決辦法是在每個(gè)執(zhí)行命令前添加 ulimit -c unlimited,但是這寫得有點(diǎn)死.另一個(gè)解決辦法是發(fā)現(xiàn)bash -c每次都會(huì)加載.bashrc,將core文件大小設(shè)置寫入.bashrc便可.
問題看起來解決了,但是我覺得這里面的一個(gè)細(xì)節(jié)和man對(duì)不上:
An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to
terminals
管理程序執(zhí)行命令時(shí)候的bash -c表示的是non-interactive shell,應(yīng)該不會(huì)加載.bashrc才是,類似于用crontab運(yùn)行的腳本就不會(huì)加載.bashrc,但是管理程序執(zhí)行命令的時(shí)候設(shè)置竟然生效了...求解.
.
PS:最近2個(gè)月沒寫blog,好忙.................
posted on 2010-12-20 23:07
LOGOS 閱讀(2184)
評(píng)論(2) 編輯 收藏 引用