事情的起因是实验室的一台服务器重启之后起不来了，看了一下发现有快硬盘坏了。 顺便看了一下，另一块也差不多了。 按理说这种事情都有监控脚本盯着，本不该发生的。 结果跑去监控的机子上一看，原来那个机子的邮件系统坏了6个月了…… 邮件系统坏掉的原因是Arch某次升级的时候貌似postfix要手动干点事情，否则就起不来。 所以光有监控系统是不够的，还需要 a. 监控监控系统的系统，这样下去貌似没完…… b. 在正常工作的时候也报告一把，这样挂了就能知道。 但是天天收到正常报告也会烦，如果都从收件箱过滤掉，那就没意义了…… 所以好像也没啥好办法…… PS. 邮件队列里堆了94万封邮件…… 上次跑实验跑出来的，幸好没发出去……
一开始是PhotonVPS，后来是linode，接着Amazon EC2，现在跑到了DigitalOcean…… 换linode因为PhotonVPS时常网络不好偶尔还重启，换EC2因为linode只有PV的虚拟机而FreeBSD一直不支持64位的PV，换DigitalOcean因为它终于支持FreeBSD了并且便宜性能好还有GitHub的100刀优惠…… 搬家倒是挺方便，把数据库、网页、配置打包拷过去就完了…… 这回能呆久一些就好了…… 毕竟搬家还是要费一些功夫的……
很久以前，我系的CRF（管理计算机资源的）来找过我，说我机子被黑了。我观察之后没啥症状，就问他们为啥那么说。 他们拿出来一个单子，说你机子往外发可疑的包，只有被黑了才发这种包。 我看了一眼，貌似我的机子在广播SNMP包。我觉得这事情也不是那么奇怪，毕竟一堆程序依赖snmp库，但是他们觉得有问题。 于是我在防火墙加了个规则，说如果有这种包就记录一下并且扔掉。其他还干了很多事情，例如换私钥之类，总之很麻烦。之后，他们就不来找我了…… 系统里的确偶尔会记录下这种包的发送记录。那时候尝试看了一眼，没看出为啥，也就没有管。 过了很久之后，一天我看着这些记录，觉得很烦躁，想着干脆研究清楚为啥会发这些破包。 首先，那些个记录里记录了发包者的UID。在我的机子上，记录的UID是colord的UID。 colord是啥呢？可以参见http://www.freedesktop.org/software/colord/intro.html。基本上是个管理色彩配置的东西，如果你不是特别关心你颜色显示得是否准确，其实有没有都无所谓。 colord发SNMP包还是很难让人理解。ldd看一眼，发现colord并没有链接libnetsnmp，net-snmp也不是他的依赖。 观察一下colord的依赖，其他貌似都挺无辜，但是有个可选依赖是sane。我机子上恰好也装了sane。 sane是啥呢？参见http://www.sane-project.org/，Scanner Access Now Easy（这Now是硬插进去的吧！），是个管扫描仪的东西。 sane倒是依赖net-snmp，所以多半是它干的好事。 之后把colord和sane代码扒下来看一眼，大概知道是怎么回事情了。 说colord有个sane插件，嘛大概扫描仪也需要色彩配置。这个插件会启动一个叫colord-sane的程序，这个程序链接到了libsane。sane有个插件叫magicolor，管理Konika Minolta的一个系列的扫描仪。 colord因为某些原因要更新设备列表，于是调进那个插件。插件启动colord-sane，导致sane也让他的插件们更新设备列表。那个magicolor系列扫描仪估计比较高级，能够联网。magicolor插件更新设备列表就去群发SNMP包，在本地网上找这个扫描仪。这个包被CRF看见了…… 其实也怪那个SNMP请求范围太广。他发的SNMP包基本上就是让本地所有的SNMP设备向他报告自己是啥设备，有啥功能之类。这看上去当然挺危险…… 最后说这个过程是怎么触发的。在开始打记录之后，我发现当我插拔手机/平板的时候，那个记录会一起出现。这种事情很容易联想到UDEV，sane和colord其实都装了UDEV规则，而这里引起问题的是colord的规则。那个规则说，只要USB设备插入/拔出，并且有gphoto支持，就给colord发个通知。Android的手机/平板当然在这个范围，于是引发了一系列事件，最后SNMP包就发出去了…… 总体现象是你插拔手机会发SNMP包，谁知道里面有这么一个过程…… 如果有个工具，能够告诉他触发条件和结果，问他中间的因果关系，倒是会方便不少。好像也不是搞不出来，不过貌似没啥学术价值……
这块希捷硬盘是我台机上硬盘里最年轻的一块，居然就挂了…… Power On Hours也就刚过一年，买来还不到两年。希捷最近真是不行…… 挂掉的是Seagate Expansion 3TB，里面的硬盘是希捷酷鱼7200.12（ST3000DM001）。 花了不少功夫拆开来，里面就是一块硬盘插在一个小电路板上。 貌似这个移动硬盘散热很糟糕，最高温度超过60，平时跑着也有55+。看看其他硬盘也就40度左右的温度，可能散热不好是挂掉原因之一。 整个硬盘盒上部完全密封，就底下有些眼，难怪散热不好…… 做了个盘面扫描，碰到坏块很慢所以就做了一点。貌似挺有规律，基本上是坏掉2块，好一块，坏掉2块，好7-8块，然后重复。每块大小大约是286M。第一个坏块是第三块。 这些坏掉的部分估计物理上有啥共同的地方，具体也不清楚。说这个硬盘是三碟装，没看出有啥关系…… 恢复数据挺麻烦的，稍微大点的文件就可能读不出来，只好跳过去。幸好这盘才用了500G，多数也不是啥重要的数据，所以损失不大…… 台机上另外的本科买的WD Elements 1TB（15862小时）一点问题也没有，开机时间都快赶上这货两倍了。 另外台机内部的其他硬盘，包括古老的西数硬盘（120G，20377小时），希捷硬盘（500G，17794小时）都没有问题。 难道传言最近希捷不行了是真的…… 以后还是避开希捷买西数算了……
说写一个monitor进程是否在跑的脚本，本来用的是ps ax | grep $sig | grep -v grep。 这个脚本写的时候好好的，用xxx.sh &跑也没问题。但是只要一关那个term分页，就挂了…… 把ps ax的内容dump出来看，居然右边被切掉了…… 那当然是宽度问题，改成ps axww就好了。想想看见过别人脚本里的ps axww，原来是这个道理…… 想是有term分页的时候，输出检测用的是term宽度，所以没有被切。分页干掉之后输出宽度没法检测了，于是用了个默认值，于是就被切掉了…… 加上ww之后想多宽就多宽，就不会被切了…… 胡写还真是能写出奇怪的bug…… 而且要不是这次$sig出现在比较靠右的位置还发现不了…… 说不定哪天换sig就莫名其妙不工作了…… ps. 其实用pgrep -f就完了么……