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

0x01 前言

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

0x02 示例代碼

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

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

當(dāng)然，如果在等待期間報(bào)錯(cuò)了，handle_client也會打印一行錯(cuò)誤日志。

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

0x03 動手演示

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

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

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

一共是10個(gè)，主要包括標(biāo)準(zhǔn)輸入輸出、epoll、及一些socket。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而EMFILE是什么呢？

它就是我們在運(yùn)行測試程序時(shí)看到的 Too many open files 這個(gè)錯(cuò)誤。

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

0x05 這個(gè)問題如何處理？

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

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

0x06 用epoll也會有這個(gè)問題嗎？

會有，epoll只是個(gè)通知機(jī)制，當(dāng)epoll檢測到有連接可被接收時(shí)，還是會通過accept來接收這個(gè)連接。

不過這里分成兩種情況。

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

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

0x07 Go是如何處理的？

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

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

這里，臨時(shí)性錯(cuò)誤就包括 EMFILE，即too many open files錯(cuò)誤：

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

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

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

0x08 Redis是如何處理的？

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

當(dāng)anetTcpAccept返回 too many open files 錯(cuò)誤時(shí)，它只打印了一行錯(cuò)誤日志，就直接return了。

不過因?yàn)閞edis使用的是level-triggered模式的epoll，所以雖然這里直接return了，但因?yàn)榈讓拥倪B接沒接收出來，epoll一直會調(diào)用這個(gè)函數(shù)，然后一直報(bào)錯(cuò)，進(jìn)而死循環(huán)。

實(shí)驗(yàn)下：

可以看到，其一直在輸出這個(gè)錯(cuò)誤。

審核編輯：劉清