話說半年前我開發了一個叫 imusutm 的 Simple Up Time Monitor。它是一個很簡單的程式：每隔 5 分鐘去 ping 一次 json 設定檔案裡面的網址，然後把它 buffer 到 RAM。同時提供一個 RESTFUL API 給 php script 來 call 並回傳最近一天的狀態。 可是不知道為甚麼，這程式很固定每隔一個月就會出現全部斷線的狀態，連帶用這系統的 Telegram bot 也一律全部報錯 在無論如何都沒辦法在本地端 reproduce 之後，在上一個月我把所有 error 裡都加入了 error message print-out 來協助除錯。結果被我發現問題了： 2023/02/24 20:20:34 Get "{某個要 ping 的 IP 地址}": dial tcp {某個要 ping 的 IP 地址}: bind: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full. 一看到這個我就明白了，原本是 socket 用光了。可是一台主機的 socket 有這麼多怎可能能全部佔用？ 原來是忘記了 resp.Body.Close() 於是我去看整段 code 唯一有用到 socket 的部分：http.Get(url)，發現忘記了寫 resp.Body.Close() 了（222 行是新加入的），所以難怪會出現這個問題。 可是，又為甚麼是大約一個月會出現一次？ Windows 的 Dynamic Port 與 ArozOS Windows 的 dynamic port range 是由 49152 到 65535。雖然有一些間中會被佔用，但是大部分都是用完之後就會被釋放出來。這兩個數字相減之後便能得出 16384 個能用的 dynamic port。 至於為甚麼是一個月？因為 每小時有 12 個 5 分鐘 x 一天 24小時 x 30天 = 8640 個 connection，然後由於 ArozOS 使用的 Go net/http 會自動斷開，而這數字又差不多是可用 port 數的一半，再加上列表上又剛好只有兩個 connection 是能維持的，我好像猜到點甚麼的樣子（？ 總括而言 相信加入了 resp.Body.Close() 之後就能解決 utm 不穩定的問題了，如果下一個月再出現類似的問題我還是整個砍掉重寫好了（畢竟這只是一個我在等上飛機時的小作品，出現這些奇怪的 bug 也不怎麼意外就是了）