發表文章

目前顯示的是 六月, 2012的文章

用 /etc/hosts.allow 設定允許的連線

man hosts.allow 有說明, 或直接看這篇的說明, 寫這篇只是強化自己記下關鍵字。現在設定允許的網段連線實在太簡單了, 記得十多年前好像很複雜, 然後記憶就停在十多年前的情況, 一直懶得看怎麼弄 ...

no space left on device

今天踏到 inode 用完的雷, "no space left on device" 除用完空間外, 也有可能是用完 inode , df 看還有剩空間時, 記得用df -i 檢查。 若要個別檢查那個目錄占掉最多 inode, 不知有沒有適當的指令, 我是用 "find DIR | wc -l" 來粗估那個目錄占掉最多個 inode。

如何監控和測量網路流量

兩個月前做的事, 現在已忘了細節, 留些連結備忘。 從 system call 下手networking - How to measure network performance (how to benchmark network protocol) 提到可以用 strace 抓網路相關的 system call 來了解傳輸量。概念不錯, 但實作用起來很麻煩, 有以下的問題: socket 也是 file descriptor, 不只可以用 send/recv 相關函式, 也可以用 read/write。要做到完全正確, 要追蹤開啟的 fd 是否為 socket 這個傳輸量不等於真正的傳輸量, 因為 TCP 有可能重傳 packet。 優點大概是可以量得很細, 像是各 thread 的傳輸量如何。若 thread 各自有特定的工作, 也許會有幫助。 從網卡下手tcdpdump: A Tcpdump Tutorial and Primer 超詳細的介紹。How to read Tcpdump Output 補足上篇的不足, 提及如何解讀輸出結果。 看完的感覺是, wireshark 似乎不如 tcpdump 強? 附帶一提, tcpdump 名為 "tcp"dump, 但是是監控網卡, 實際上可看各種不同 protocol, 不只 tcp, 滿容易使用的。 IPTraf 附 screenshot 的簡短介紹: 唉呦~MIS先生: 好用的流量監控程式--IPTraf, 可觀看即時流量。很容易操作, 功能也很彈性。不過若要用在反覆執行的測量程式, 可能還是配合 tcpdump 再寫分析的 script 比較方便。

使用 Mac 產品觸控輸入的心得

和 MacBook Air 以及 iPad、iPhone 相處的時間多了一些後, 覺得 Apple 在輸入方式下的工夫真是相當深。 一樣是觸控的輸入方式, 可分成考慮螢幕所在位置和不考慮兩種用法, 比方說 MacBook 的 mouse pad 可用三指向左右滑, 切換畫面; 還有用兩指上下左右滑, 以捲動視窗。前者沒考慮螢幕游標的位置, 後者有。 在 iPad 上可用四指左右滑切換 App, 但在 iPhone 上找不到開啟這功能的選項, 也許是覺得在 iPhone 上用四指不合一般使用電話的姿勢, 寧願讓使用者透過 home 鍵切 app。 題外話, 使用這些裝置的過程中我也才明白實體鍵盤設計的巧妙之處。實體鍵盤的觸感讓我 100% 確定手指在的位置, 還有敲鍵的次數。所以我可以安心地看著另一個裝置的網址, 盲打一串長網址而不會輸入錯。 但反過來要用 iPad / iPhone 輸入網址時, 成功率實在太低, 以致於我寧願先用縮網址服務, 再回到 iPad / iPhone 上輸入縮址。若這個「將桌機的網址「傳到」行動裝置」的使用情境很廣的話, 也許值得針對此點寫個功能, 目前是覺得不值得就是了

寫 linux daemon 的注意事項

一直以來都很納悶為什麼寫 daemon 時需要 double fork, double fork 是必要的嗎? 最後才發覺我問錯問題了, 而問錯問題永遠不會得到對的答案。我該問的問題是, 成為一個 daemon, 必須該做那些事? 答案是: chdir("/"): 避免有任何目錄因為還有 process 在路徑內, 使得目錄已被移除, 卻無法釋放空間。 避免成為 zombie: 若 daemon 的 parent process 是 init 的話, daemon 結束時 init 會自動 wait 它, 避免成為 zombie。反之, 則有這點顧慮。 脫離 terminal: 因為關閉 terminal 的時候, kernel 會送 SIGHUP 給 session leader [*1]。以 shell 的實作來說, shell 是 session leader, 它在收到 SIGHUP 時, 會送 SIGHUP 給它所產生的所有 process group, 而 SIGHUP 預設行為是 terminate。但這不是 daemon 希望的行為, 相較於因此改變 SIGHUP 的行為, 不如脫離 terminal 更省事, 還可視需要保留 SIGHUP 做別的用途 [*2] 同上, 脫離 terminal 可避免不小心讀寫到 terminal 而收到 SIGTTIN 和 SIGTTOU。它們是 background process 讀寫 terminal 時觸發的, 藉由這樣告知 process 它目前是 background process 並嘗試要讀寫 terminal。雖然也可以改變這兩個 signal 的處理行為 (預設為 stopped), 但是不如完全不會發生來得省事。 有了以上需求, 就有不同的作法。POSIX 沒有定義 daemon() 函式, 不過 BSD 體系包含 Linux 裡有 daemon() 函式, 用來成為 daemon。eglibc 的實作方式如下: fork 一次, 讓 parent process 掛掉, 以滿足 (2) 呼叫 setsid() 成為新的 session leader chdir("/"), 以滿足 (1) 重導 0, 1, 2 到 /dev/null 以滿足 (3、…

在 Linux 上找執行時間的瓶頸

記錄一下自己加速程式的心得。重點是: 有個可靠且易於重覆執行的方式, 來計算執行時間。 logging我最常用的方法是手動 logging 計算函式的執行時間。通常我有兩種作法 在函式的開頭取得系統時間, 離開時再最得系統時間, 兩者相減得到執行的時間。 [*1] 使用一個會自動附上 timestamp 的 logging function, 會記錄這次到上次 log 的時間差, 或事後用外部 script 算出各筆 log 之間的時間差。這樣可以在懷疑的函式不同地方做 log, 了解各區塊的執行時間。 PS *1 實作細節 像 Python 有 decorator 的語法, 可以寫個 log_time(), 內容是「取得時間、執行目標函式、取得時間並記錄相減結果、傳回目標函式的傳回值」, 再用 decorator 的語法加到有興趣的函式上。 C++ 的話, 可以寫個 class LogTime, 在 constructor 以及 destructor 計時, 達到同樣效果。然後在目標函式的第一行宣告 LogTime log。 優點 可以明確抓出函式花的時間, 對於「加快程式」來說, 是最確實的反應。不論是真的 CPU bound 或 lock 或 I/O 導致緩慢, 都會反應在 log 裡。 可自行控制 log 函式的細膩度, 比方說先抓出 sort() 最花時間, 再來到 sort 裡放 log, 觀察在 sort 的那部份最花時間。 缺點 得自己手動在懷疑的部份加上 log 函式, 不方便大範圍無腦偵查。使用 profilerlinux - Alternatives to gprof 列了不少工具, 大概掃過了這篇, 也試了一下, 這部份的經驗很淺, 下面可能會有些錯誤, 像是對工具的錯誤認知, 或少用了什麼功能而覺得不好用。 感覺上這類工具只能反應出真的 CPU bound, 若原因是 lock 或 I/O 拖慢效能, 需要用其它管道查明源頭。 我是在 VirtualBox 裡的 Ubuntu 11.04 試用。選用的前提是對實際執行的負擔要低, 愈接近原本情況愈好。 perfperf 很容易使用, 基本指令: perf record CMD # 執行並記錄 CMD perf record -p PID # 記錄 process PID perf re…

注意 ptrace 的權限設定

gdb、strace 都是用 ptrace 來監控另一個 process 的情況, 經 wens 提醒關於權限設定的事。 基於安全考量, Ubuntu 10.10 開始, 即使 effective uid 相同, 預設只能對後代 process 用 ptrace。其它情況得用 root 權限執行才可以。在自己的開發機上, 為了方便起見, 可以取消這個限制: 更改目前設定: echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope sysctl 開機後自動生效: 改 /etc/sysctl.d/10-ptrace.conf