的情況如下：處理文本文件
一系列遠程工作站採集現場數據，並通過FTP的FTP收集到的現場數據的服務器。數據作爲CSV文件發送，存儲在FTP服務器中每個工作站的唯一目錄中。
每個工作站每隔10分鐘發送一次新更新，導致先前的數據被覆蓋。我們想以某種方式自動連接或存儲這些數據。工作站的處理是有限的，不能擴展，因爲它是一個嵌入式系統。
提供的一個建議是在FTP服務器上運行cronjob，但是有一個服務條款限制只允許30分鐘的時間間隔cronjob，因爲它是共享託管的。鑑於上傳工作站的數量和上傳時間間隔爲10分鐘，看起來cronjob的30分鐘呼叫限制可能是一個問題。
有沒有其他方法可能會被建議？可用的服務器端腳本語言是perl，php和python。
升級到專用服務器可能是必要的，但我仍然想以最優雅的方式獲得有關如何解決此問題的輸入。
大多數現代Linux將支持inotify，讓你的過程知道指令的內容何時改變，所以你甚至不需要輪詢。
編輯：對於下面的馬克·貝克的評論：
「不過要小心，因爲你會盡快創建文件通知，而不是當它關閉所以你需要一些確保你不會拿起部分文件的方式。「
這會發生在您在目錄級別設置的inotify監視器上 - 確保您不會接收部分文件的方法是在新文件上設置更多inotify監視並查找IN_CLOSE事件以便您知道該文件已完全寫入。
一旦你的過程看到了這個，你可以刪除這個新文件的inotify監視，並在閒暇時進行處理。
你可能會考慮一個持久的守護進程，保持投票的目標目錄：
grab_lockfile() or exit();
while (1) {
if (new_files()) {
process_new_files();
}
sleep(60);
}
然後你的cron作業可以直接嘗試啓動守護每30分鐘。如果守護進程無法獲取鎖文件，它就會死掉，所以不用擔心運行多個守護進程。
另一種考慮的方法是通過HTTP POST提交文件，然後通過CGI處理它們。這樣，您保證在提交時已經妥善處理了它們。
30分鐘的限制真的很愚蠢。在Linux中啓動進程並不是一個昂貴的操作，所以如果你所做的只是檢查新文件，沒有理由不這麼做。我們有每分鐘運行的cron作業，並且它們對性能沒有任何明顯的影響。但是，我意識到這不是你的規則，如果你打算堅持使用該託管服務提供商，你就沒有選擇。
您需要某種長時間運行的守護進程。簡單的方法是定期進行投票，可能這就是我所要做的。Inotify，所以一旦創建文件就會收到通知，這是一個更好的選擇。
你可以從perl中使用inotify與Linux :: Inotify，或者從python與pyinotify一起使用。
但要小心，因爲一旦文件被創建，您就會收到通知，而不是在它關閉時收到通知。所以你需要一些方法來確保你不會拿起部分文件。
通過輪詢，您不太可能會看到部分文件，但它最終會發生，並且在發生時會是一個令人討厭的難以重現的錯誤，現在更好地處理這個問題。
如果你想保留現有的FTP服務器設置，那麼我建議使用類似inotify或daemonized的過程來觀察上傳目錄。如果您可以移動到不同的FTP服務器，那麼您可以看看pyftpdlib這是一個Python FTP服務器庫。
我一直是pyftpdlib開發小組的一部分，而一個更常見的請求是一種方式來處理文件，一旦他們完成上傳。因此，我們創建了一個on_file_received()回調方法，該方法在完成上傳時觸發（請參閱我們的問題跟蹤器上的issue #79以瞭解詳細信息）。
如果您對Python感到滿意，那麼運行pyftpdlib作爲您的FTP服務器並從回調方法運行處理代碼可能會很好。請注意，pyftpdlib是異步的而不是多線程的，所以你的回調方法不能被阻塞。如果你需要運行長時間運行的任務，我會建議一個單獨的Python進程或線程用於實際的處理工作。