python腳本使用sched模塊每60秒運(yùn)行一組類函數(shù)：# sc is a sched.scheduler instancesc.enter(60, 1, self.doChecks, (sc, False))該腳本使用此處的代碼作為守護(hù)進(jìn)程運(yùn)行。doChecks的一部分調(diào)用的許多類方法使用子過(guò)程模塊來(lái)調(diào)用系統(tǒng)函數(shù)，以獲取系統(tǒng)統(tǒng)計(jì)信息：ps = subprocess.Popen(['ps', 'aux'], stdout=subprocess.PIPE).communicate()[0]在整個(gè)腳本崩潰并出現(xiàn)以下錯(cuò)誤之前，它可以正常運(yùn)行一段時(shí)間：File "/home/admin/sd-agent/checks.py", line 436, in getProcessesFile "/usr/lib/python2.4/subprocess.py", line 533, in __init__File "/usr/lib/python2.4/subprocess.py", line 835, in _get_handlesOSError: [Errno 12] Cannot allocate memory腳本崩潰后，服務(wù)器上free -m的輸出為：$ free -m                  total       used       free     shared     buffers    cachedMem:                894        345        549          0          0          0-/+ buffers/cache:  345        549Swap:                 0          0          0服務(wù)器正在運(yùn)行CentOS 5.3。我無(wú)法在自己的CentOS盒子上或任何其他報(bào)告相同問(wèn)題的用戶上進(jìn)行復(fù)制。我已經(jīng)嘗試了許多方法來(lái)調(diào)試此問(wèn)題，如原始問(wèn)題中所建議的那樣：在Popen調(diào)用之前和之后記錄free -m的輸出。內(nèi)存使用沒(méi)有顯著變化，即，隨著腳本運(yùn)行，內(nèi)存不會(huì)逐漸耗盡。我在Popen調(diào)用中添加了close_fds = True，但這沒(méi)有什么不同-腳本仍然因相同的錯(cuò)誤而崩潰。建議在這里和這里。我檢查了這所建議雙方RLIMIT_DATA和RLIMIT_AS顯示（-1，-1）的rlimits 這里。一篇文章建議沒(méi)有交換空間可能是原因，但是交換實(shí)際上是按需提供的（根據(jù)Web主機(jī)），這在這里也被認(rèn)為是虛假的原因。進(jìn)程已關(guān)閉，因?yàn)檫@是使用.communicate（）的行為，該行為由Python源代碼和此處的注釋支持。整個(gè)檢查都可以在GitHub上的第442行定義的getProcesses函數(shù)中找到。這由doChecks（）從520行開(kāi)始調(diào)用。