我們有一個運行一個命令來執行以下命令節點js腳本:PHP CLI腳本沒有超時
/usr/local/bin/php -q /home/www/441.php {"id":"325241"}
這個腳本的東西很多但它似乎不尊重時間限制。該文件的第一行是:
set_time_limit(1800);
然而,如果我們檢查哪些進程正在服務器(ps -aux | grep php
)上運行,我們會看到很多的這些命令已經自上週開放式的。
關於我們如何清理它的任何想法?
我們有一個運行一個命令來執行以下命令節點js腳本:PHP CLI腳本沒有超時
/usr/local/bin/php -q /home/www/441.php {"id":"325241"}
這個腳本的東西很多但它似乎不尊重時間限制。該文件的第一行是:
set_time_limit(1800);
然而,如果我們檢查哪些進程正在服務器(ps -aux | grep php
)上運行,我們會看到很多的這些命令已經自上週開放式的。
關於我們如何清理它的任何想法?
set_time_limit
只對程序的php部分有意義。如果您對需要5小時完成的數據庫進行查詢,那麼5h不會被php計算在內,因此它們超出了set_time_limit
限制的範圍。話雖如此,似乎有點奇怪的是,如果一個php進程沒有調用永遠運行的另一個程序(在這種情況下,set_time_limit
既不影響該調用),它仍在運行一週後仍然運行。
另外,-q
標誌是什麼?我無法在man php
或php --help
以及php's command line options中找到它。
我發現PHP的用戶指南的max_execution_time
以下注釋請記住,對於CLI SAPI 的max_execution_time是硬編碼到0 所以它似乎是由的ini_set 或參數或者set_time_limit但它可以改變實際上不是, 。我發現 只有 發現這個奇怪的決定是 深入bugtracker (http://bugs.php.net/37306)和 php.ini( 「max_execution_time」指令的意見)。
因此,似乎CLI模塊中存在一個錯誤,意味着max_execution_time被有效忽略。
該評論者在錯誤跟蹤器中提到了一個關於此的頁面,其網址爲http://bugs.php.net/37306,但跟蹤器似乎已關閉。
如果你在nodejs中啓動腳本,爲什麼不在那裏殺死它呢?
var pid = startPHPProcess();
setTimeout(function() {
killPHPProcess(pid);
}, 1800);
-q是安靜模式。抑制HTTP標頭輸出(僅限CGI)。 – fire
謝謝,我認爲問題出在PHP腳本調用的另一個軟件上,那就是不掛載PHP本身,這就是爲什麼set_time_limit不起作用。 – fire