JASONT

剛剛在機器上 top 時發現了沒注意過的 process，User 是 haldaemon，process 是啥 hald-runner、hald 之類的，後來去 redhat 上查了一下，順便了解一下 HAL 是什麼東西

其實他的概念很簡單，主要是用來做為一個硬體與AP的中繼，讓不同的硬體在系統上可以更便利的被使用。一張圖就足以解釋了。

有興趣研究的可以再去 Redhat 網站上看更細的說明。

這部片大概是我這一兩個月看不少片子下來，唯一一部讓我覺得超棒的一部片。劇情描述美國總統被槍擊的事件，劇情本身沒有什麼特殊之處，但這部片厲害的地方是以不同人物的角度，去重覆播出同一段時間內發生的時，一開始乍看不相干的人物，其實都是這部片的一個環結，也許這一段你有不懂的地方，但下一段由另一個人物的角度拍攝，你馬上能夠了解，實在是很特殊的拍攝方法，很佩服導演。

這部片沒有刻意著重大場面，但開頭的爆炸及中後段在車水馬龍的小鎮馬路上飆車追逐，也是很夠味的，這部片真的是不錯超棒值得一看的片。

這兩天在查公司 Radius 的問題，用戶在某個特定類型的 HotSpot 上線就一定不會驗證過，可是怎麼看 Packet 帶的 Attribute 就是沒有特別之處，只好先開 Debug Mode 慢慢追，Freeradius 只要開 -X 再 redir 到某個檔就能記下 Debug 的記錄，但 Livingstone 這骨董，怎麼倒都不行，最後還是看了一下  Code（一開始早看就沒事了 XD）

if (debug_flag) {
        if (radius_log == (char *)NULL) {
                /*
                 * for backward compatibility
                 * send messages to users tty
                 */
                radius_log = "/dev/tty";
        } else if (strcmp(radius_log, "syslog") == 0) {
                /*
                 * allow user to override backward compatibility
                 * and send debug to syslog
                 */
                radius_log = (char *)NULL;
        }
} 

如果開 debug mode，除非 -l 後面設的是 syslog，不然設啥鬼都不會鳥你的.. XD 囧…. 記一下…

前陣子公司一台主機因為 Session 檔都沒砍，空間還有，但卻把 Inode 用完了，因此 Cacti 除了監控硬碟空間量以外，現在要加上 Inode 監控。

Inode 的 MIB 在 UCD/Net-Snmp 裡是有的，MIB 值為 .1.3.6.1.4.1.2021.9.1.10

看了一下 Cacti 內 resource/snmp_queries/net-snmp_disk.xml 已經有設定了一些 Disk 部份的MIB，就唯獨沒有設定到 inode 的，因此只要在最後面再加上這一段

　　<dskPercentNode> 　　　
　　　<name>Inode Percent Used</name>
　　　<method>walk</method>
　　　<source>value</source>
　　　<direction>output</direction>
　　　<oid>.1.3.6.1.4.1.2021.9.1.10</oid>
　　</dskPercentNode>

設定完以後，再到 Cacti 後台去，在 ucd/net – Get Monitored Partitions 的 Data Query 裡加上一個 Inode Status 的 Associated Graph Templates，設完以後去把 Data Template 和 Graph Template 設一設，最後在 Device 裡，Create graph for this Host 時，ucd/net – Get Monitored Partitions 的 Data Query 就會有兩個選項可以選，一個是空間用量，一個是剛剛建完的 Inode，這樣點一點就完成了，沒有比較特殊要設定的地方。

（不過一次一百多台的要一個一個去建新圖，點到我到快殺人了…）

是的，16400~多麼神奇的數字，這是目前公司兩台提供用戶發信的主機上Queue信的數量合計，這還是經過我下班前一個多小時的努力才會減少到這樣，原本一台上面應該都是破一萬五。

由於本公司目前使用的郵件主機效能實在是太好了，這個 Queue 信的數量不減反增，更別提上面還看的到三天前的信在上面，我真是一整個快噴血了…

一整個無力.. 我知道我們有問題廠商也會盡力幫我們解決，而更因有幾個問題還沒解決被壓了兩季的維護費用還沒付.. 真是賺辛苦錢啊！

只是… 這種效能我快要覺得和另一間之前被我嫌到沒力的廠商快要有相同等級的感覺了.. 誰來救我… :~~~

真是沒看過採用外面的 Solution ，搞到最後自己還要跳下來另外做出 Solution 解決這個 Solution 發生的問題.. God.. God…. God……….

別再混了… 再混走路的是自己先… 乖乖趕 Proposal 吧.. 唉…. 唉一下…..