什麼是簡單的方法來測試某個給定ID的進程是否目前在Linux上運行？

在C++中，我有一個綁定到pid的資源。有時與該pid關聯的進程會異常退出並泄漏該資源。什麼是簡單的方法來測試某個給定ID的進程是否目前在Linux上運行？

因此，我正在考慮將pid放在記錄資源被使用的文件中。然後，當我去獲取資源時，如果我看到一個已註冊爲正在使用的項目，我將搜索以查看是否正在運行與pid匹配的進程，如果沒有，則清理泄漏的資源。

我意識到有一個非常小的可能性，一個新的未分析的pid現在共享相同的數字，但這比漏掉我現在沒有清理更好。

另外，也許有一個更好的解決方案，如果是這樣，請建議，否則，我會追蹤錄像。

更多詳細信息：資源是用於通過tcp在客戶端和服務器之間進行通信的端口號。客戶端只有一個實例可以在機器上使用給定的端口號。端口號取自一系列可用端口號。在客戶端運行時，它會記錄它在磁盤上的特殊文件中使用的端口號，然後在退出時清除該條目。對於異常退出，這並不總是得到清理，端口號被註釋爲正在使用，當它不再被使用時。

來源

2010-07-05 WilliamKF

你想要什麼系統？在Windows下，它不同於Linux。 – 2010-07-05 18:07:33

如果您正在運行linux，您可能需要查看實用程序pidof。如果你找到你自己的pid，你正在運行。 – 2010-07-05 18:10:07

假設pid不會重複它自己的罰款。除非你有成千上萬的短命進程 – 2010-07-05 18:43:21

要檢查給定ID的進程的存在，使用kill(pid,0)（我假設你在POSIX系統上）。詳細信息請參見man 2 kill。

此外，您可以使用waitpid呼叫在流程結束時收到通知。

來源

2010-07-05 18:06:54

我建議你使用某種操作系統資源，而不是PID。互斥體，信號量，關閉時刪除文件。當一個進程退出時，所有這些都由操作系統清理。

在Windows上，我會推薦一個命名互斥鎖。

在Linux上，我會建議在文件上使用flock。

來源

2010-07-05 18:10:44

我不知道在Linux上執行delete-on-close的方法。請注意，您可以在打開文件時刪除文件，然後在最後一個文件句柄關閉時刪除文件。當然，一旦刪除，訪問它的唯一方法就是通過其中一個現有句柄，所以這可能對你沒有用處。 – 2010-07-05 19:06:11

的確如此，但「flock」（文件諮詢鎖定）將被釋放。這是其他進程可以檢測到的。不過，我可能會選擇使用'kill（PID，0）'的建議，或者檢查PID 1234是否存在'/ proc/1234'。（但是你的評論讓我有點困惑。隨後被刪除的評論？） – 2010-07-05 19:34:49

問題域不明確，不幸的是，您可以嘗試以其他方式重新解釋它。

但是，如果我理解正確的話，你可以創建一個地圖就像

std::map< ProcessId, boost::shared_ptr<Resource> > map; 
// `Resource` here references to some abstract resource type 
// and `ProcessId` on Windows system would be basically a DWORD

在這種情況下，你只需要列出所有正在運行的進程（這可以通過EnumProcesses call在Windows上進行），並刪除所有從您的map輸入不正確的ID。這樣做之後，您將只剩下有效的過程資源對。取決於您的需求，此操作可以在每個YY秒重複。請注意，在這種情況下，從您的地圖中刪除一個項目基本上會調用相應的析構函數（因爲如果您的資源未在其他地方的代碼中使用，則它的引用計數將降至零）。

來源

2010-07-05 18:14:39

其實現了對窗口是OpenProcess這需要進程ID作爲輸入，並GetExitCodeProcess返回STILL_ACTIVE當處理是，那麼，仍然活躍的API。您也可以使用任何具有零超時的Wait函數，但此API看起來更清晰。

然而，正如其他答案所指出的，這似乎並不是一條有希望的道路。如果您提供更多的場景細節，我們可能會提供更專注的建議。你的平臺是什麼？什麼是泄漏資源？您是否有權訪問泄露的應用程序代碼？你可以用一些清理工具把它包裝在一個高級別的try-catch中嗎？如果沒有，那麼可以等待泄漏者完成一個專用線程（或完全專用的進程）？您提供的任何細節可能都有幫助

來源

2010-07-05 18:29:55

現在在上面添加更多細節。 – WilliamKF 2010-07-05 18:42:31

所以 - 它確實是Windows？所說的客戶端是你的代碼的一部分嗎？在你的情況下建議的替代方案是否有意義？ – 2010-07-05 18:59:16

由於標題表示Linux，我懷疑對Windows API函數的引用是否有幫助。 – 2010-07-05 19:31:56

如果啓動進程的主進程（異常終止的進程）等待進程崩潰（waitpid），並在waitpid返回時再次產生進程，那麼它如何呢？

while(1) { 
fork exec 
waitpid 
}

來源

2010-07-05 18:49:02

這是管理進程的唯一理想方式，至少在Unix上。 – 2010-07-05 19:04:50

什麼是簡單的方法來測試某個給定ID的進程是否目前在Linux上運行？

回答

相關問題