Too many open files錯誤導致服務(wù)器死循環(huán)

0x01 前言

在服務(wù)器編程中，經(jīng)常會遇到 Too many open files 這個報錯，而且這個報錯如果處理不好，很有可能會導致服務(wù)器死循環(huán)。

0x02 示例代碼

以上是我用rust寫的一個非常簡單的tcp服務(wù)器，它的主要邏輯是，先創(chuàng)建一個listener，然后再在循環(huán)里不斷調(diào)用listener.accept接收tcp連接，如果接收成功，就調(diào)用handle_client處理這個連接，如果接收失敗，就打印一行錯誤日志。

handle_client里的邏輯也非常簡單，就是等待客戶端關(guān)閉連接，或等待其發(fā)送任意數(shù)據(jù)，當這兩種情況發(fā)生時，handle_client就會直接關(guān)閉這個連接。

當然，如果在等待期間報錯了，handle_client也會打印一行錯誤日志。

下面我們就會使用這段程序，來演示服務(wù)器死循環(huán)的情況，這段程序不必非要用rust編寫，用其他語言也都可以。

測試代碼我已經(jīng)放到github了，如果想要自己動手測試的，可以clone下來自己試下。

代碼地址：https://github.com/ytcoode/too-many-open-files

0x03 動手演示

先啟動該服務(wù)器：

由上圖可見，該服務(wù)器的進程id是312004，監(jiān)聽地址是0.0.0.0:9999。

再查看下該服務(wù)器已打開的文件數(shù)：

一共是10個，主要包括標準輸入輸出、epoll、及一些socket。

再查看下該服務(wù)器進程最多可打開的文件數(shù)：

看選中行，Soft Limit那一列，其表示該進程最多可用的文件描述符數(shù)量為1024個，即最多可同時打開的文件數(shù)為1024個。

我們把它改小一點，方便后續(xù)測試：

上圖中，先使用prlimit命令將該服務(wù)器進程的Max open files數(shù)改成12，然后再用cat命令確認下該改動已生效。

至此，我們已經(jīng)設(shè)置好該服務(wù)器進程最多可用的文件描述符數(shù)量為12，其當前已用的文件描述符數(shù)量為10，所以該服務(wù)器最多還可以再接收2個tcp連接。

我們用 `ncat localhost 9999` 命令建立連接試一下，當然你也可以用telnet, nc等其他命令，只要能建立tcp連接就行：

由上圖服務(wù)器日志可見，該tcp連接已建立成功。

再看下當前服務(wù)器已使用的文件描述符數(shù)量：

由上圖可見，新建socket使用的文件描述符為10，當前服務(wù)器進程已使用11個文件描述符，到目前為止一切正常。

用同樣的命令再建立一個tcp連接，這次應(yīng)該也能連接成功，不過會有一些有意思的事情發(fā)生：

首先看上圖中最后一行info日志，它表示第二次tcp連接也建立成功了，如果此時去看文件描述符數(shù)量，也正好是12。

不過此次連接建立也導致不斷的error日志輸出，該服務(wù)器死循環(huán)了。

但此時，如果我們關(guān)閉第二次ncat命令建立的tcp連接，服務(wù)器又不會一直輸出error日志了，它又會恢復(fù)到正常狀態(tài)：

看上圖中的最后一條info日志，它表示第二個tcp連接正常關(guān)閉了，且當前已建立的連接數(shù)量是1。

此時，如果我們?nèi)タ次募枋龇麛?shù)量，其也變成了11，這里就不再截圖了，有興趣的可以自己動手試下。

0x04 為什么會出現(xiàn)死循環(huán)？

首先，在linux的世界里，一切皆文件，這里就包括socket。

其次，linux為保證系統(tǒng)的整體性安全，為每個進程限制了其最大可使用的文件描述符數(shù)量，即最大可打開的文件數(shù)，這個數(shù)量就是上面我們用 `cat /proc/$(pidof too-many-open-files)/limits` 命令輸出的Max open files行，Soft Limit列對應(yīng)的值，該值是可以通過各種方式修改的，在我的系統(tǒng)上，該值默認為1024。

接著，我們啟動了服務(wù)器，然后通過 `l /proc/$(pidof too-many-open-files)/fd/` 命令查看該服務(wù)器已使用的文件描述符數(shù)量，其為10。

之后，我們用prlimit命令將該服務(wù)器進程最大可使用的文件描述符數(shù)量改成了12，這樣該服務(wù)器就還只剩兩個文件描述符可用。

再之后，我們用ncat命令建立了兩個tcp連接，在服務(wù)器端的循環(huán)里，accept接收到這兩個連接并進行處理，此時該服務(wù)器進程消耗完了最后兩個可用的文件描述符。

接下來，服務(wù)器代碼進入下一次循環(huán)，繼續(xù)調(diào)用accept嘗試接收新的連接，問題的關(guān)鍵點也就出現(xiàn)在了這里。

accept是個系統(tǒng)調(diào)用，我們看下其對應(yīng)的內(nèi)核實現(xiàn)：

這個是accept系統(tǒng)調(diào)用的入口函數(shù)，沿著函數(shù)調(diào)用，可找到以下代碼：

由上圖可見，在真正的do_accept之前，會先調(diào)用get_unused_fd_flags找一個還未被使用的文件描述符，如果尋找時報錯了，即newfd < 0，則直接返回該錯誤碼給用戶層，如果找到了一個可用的文件描述符，則開始執(zhí)行真正的accept操作。

繼續(xù)看get_unused_fd_flags函數(shù)：

它在調(diào)用其他函數(shù)之前，會通過 rlimit(RLIMIT_NOFILE) 獲取當前進程最大可使用的文件描述符數(shù)量，即我們上面通過prlitmit命令設(shè)置的12。

繼續(xù)往下看，我們會找到以下代碼：

該函數(shù)的目的是分配一個文件描述符，即fd，圖中選中行之前是找到一個還未被使用的fd，然后判斷該 fd 是否 >= end，如果是，則goto到out，進而return error，而這個error就是EMFILE。

那end值是什么呢？它就是上面用 rlimit(RLIMIT_NOFILE) 獲取的當前進程最大可用的文件描述符數(shù)。

結(jié)合上面的例子我們知道，當服務(wù)器接收完兩個tcp連接后，其最大可使用的12個文件描述符已全部被用完，當其循環(huán)到下一次accept系統(tǒng)調(diào)用后，會最終進入到上圖這個函數(shù)，這次新分配的fd值一定是12（因為fd值從0開始的，所以fd值為12表示第13個文件描述符），而我們又限制了該進程最大可用12個文件描述符，即我們限制了end值為12，所以在上圖選中行進行判斷時，fd 一定是 >= end 的，所以，該函數(shù)一定會返回EMFILE這個錯誤碼。

而EMFILE是什么呢？

它就是我們在運行測試程序時看到的 Too many open files 這個錯誤。

示例程序調(diào)用accept收到這個錯誤碼后，會打印一行error日志，然后繼續(xù)循環(huán)調(diào)用accept，然后繼續(xù)報錯，就這樣，服務(wù)器就在accept這里發(fā)生了死循環(huán)。

0x05 這個問題如何處理？

因為 too many open files 是個臨時性錯誤，當進程中的其他地方關(guān)閉了一些文件，或者管理人員調(diào)高了該進程的 max open files值，accept就不會再報 EMFILE 錯誤，也就不會再死循環(huán)了。

所以其處理方法也很簡單，就是在accept發(fā)生錯誤時，sleep一段時間，這樣既防止了cpu 100%的發(fā)生，也給進程時間來調(diào)整已用及最大的文件描述符數(shù)。

0x06 用epoll也會有這個問題嗎？

會有，epoll只是個通知機制，當epoll檢測到有連接可被接收時，還是會通過accept來接收這個連接。

不過這里分成兩種情況。

當使用epoll的edge-triggered模式時，正確寫法是要一直循環(huán)調(diào)用accept接收連接，直到其返回 EAGAIN 或 EWOULDBLOCK 錯誤碼，表示已經(jīng)沒有連接可接收了，這時才能退出accept循環(huán)，但如果在這之前accept返回了 too many open files 這個錯誤，就會發(fā)生死循環(huán)了。

當使用epoll的level-triggered模式時，可以不必一直循環(huán)調(diào)用accept直到其返回EAGAIN 或 EWOULDBLOCK，可以提前退出，但如果操作系統(tǒng)里還有建立好的連接等待被接收，epoll還是會一直通知應(yīng)用層，告知其要調(diào)用accept接收這些連接，如果此時文件描述符沒有了，accept還是會一直報 too many open files 錯誤，最終還是進入到了死循環(huán)。

0x07 Go是如何處理的？

下面我們看下go內(nèi)置的http服務(wù)器，是如何處理這個問題的：

當accept返回err后，其會通過ne.Temporary()來檢查該err是否是臨時性錯誤，如果是，則會根據(jù)一定的規(guī)則，sleep一段時間。

這里，臨時性錯誤就包括 EMFILE，即too many open files錯誤：

我們也可以寫個簡單的例子測試下：

按照之前的方式，讓其觸發(fā) too many open files 這個錯誤：

由圖可見，和我們上面分析的一樣，其也陷入了死循環(huán)，但是它用sleep的方式，防止cpu使用率100%。

0x08 Redis是如何處理的？

下面我們看下redis是如何處理這個問題的：

當anetTcpAccept返回 too many open files 錯誤時，它只打印了一行錯誤日志，就直接return了。

不過因為redis使用的是level-triggered模式的epoll，所以雖然這里直接return了，但因為底層的連接沒接收出來，epoll一直會調(diào)用這個函數(shù)，然后一直報錯，進而死循環(huán)。

實驗下：

可以看到，其一直在輸出這個錯誤。

0x09 結(jié)語

希望通過這篇文章，能給大家的技術(shù)水平帶來一點提高。