纠结这个问题的原因还是——完美主义造成的格式问题。很久以前Kaijia一直在用Word的格式，即英文和中文之间没有空格填写提交注释，今年暑假看了微软的设计规范文档之后Kaijia开始采用英文和中文之间有空格的形式。所以这次Kaijia将原来储存在SVN中的内容导入到Git时特纠结打算将之前的格式全部换过来。于是Google了一下批量修改Git提交注释的方法。
一开始还没有找到，当然主要原因还是一般人只会遇到需要修改最近的一条注释的情况，仔细重新看了一遍后在一篇Stack Overflow中的一个非最受欢迎答案中找到了方法。
从没有IO瓶颈的OpenVZ切换到KVM之后各种问题就会体现为不正常的CPU负载，比如这次Kaijia在为Apache服务器添加了mod_pagespeed模块支持后就遇到了这个问题。在启用了mod_pagespeed以及其他几个模块后，Kaijia查看CPU负载的监控记录时发现启用mod_pagespeed模块前后的CPU负载差距异常大。
系统监控显示PageSpeed启用前后CPU负载对比
由于同时启用了多个新模块，所以Kaijia还不能确定到底是哪个模块的问题。Kaijia打开Apache的错误日志查看记录，结果无论使用vim还是nano都转了半天没有动静。一般这种情况都是由于IO造成的，于是Kaijia查看了一下error.log的大小，结果发现error.log居然有242MB（这。。。）。
|
1 2 |
root@kaijia:/var/log/apache2# ll -rw-r----- 1 root adm 254793457 1月 8 16:38 error.log |
今天Kaijia遇到了一件郁闷事。Kaijia登录一台由OnApp驱动的Ubuntu VPS时发现系统里有些早前的内核可以删除，于是Kaijia用dpkg列出了所有旧内核，全部删除了并且执行了update-grub更新GRUB引导的menu.lst。update-grub没有提示错误，更新完成之后重启服务器，结果Kaijia等了很长时间都无法连接SSH，登录到管理界面一看才发现是VPS无法成功启动了。
于是Kaijia尝试使用OnApp提供的Console，但是当VPS关闭时Console是不可用的。重复几次尝试启动系统失败后，Kaijia确认是由于内核无法载入导致GRUB失败，因此此时只能使用OnApp提供的Recovery Console尝试修复系统。搜索了一些资料后Kaijia找到了OnApp官方提供的使用文档，按照文章的提示成功修复了系统。
通过管理面板启动OnApp恢复模式
这也许是自从在笔记本上安装了Windows 7以来Kaijia第一次遇到的不明故障。至今Kaijia仍然无法确认造成错误的具体操作，因为在一次开机后系统，系统任务栏的Aero界面突然消失并且提示“Windows无法连接到System Event Notification Service服务”，对System Event Notification Service服务手动配置并且重启后问题仍然存在。
Windows无法连接到System Event Notification Service服务错误提示
Kaijia回想起上一些使用Windows时的操作——用Word 2010制作了一个模板文件并且安装并删除了多个版本的冬青黑体字体。这看起来和这次遇到的问题八竿子都打不到一次，这是Kaijia第一次对Windows系统完全没有头绪。Kaijia尝试通过修复Aero界面来修复这个问题，但是系统直接提示无法执行体验指数评分。于是Kaijia只能将各种症状描述成英文去微软的论坛中寻找类似的情况，最后在TechNet中找到了一篇《Could not connect to System Event Notification Service》的帖子，其中也提到了这个问题是由于字体缓存造成的。Kaijia按照帖子中提供的基础方法尝试清除字体缓存但是并没有成功，然后一位名叫Lany Zhang的用户回帖说注意微软的热修补KB2590550。
考虑到iPlacard和Info Flow日益庞大以及今后开发的需要，今天Kaijia在自己的服务器上安装了GitLab以实现更好的团队开发。安装完成后一切运行正常，但是当Kaijia要把iPlacard的SVN导入到GitLab时却遇到了问题。
Kaijia首先通过git svn命令将原有的SVN库转换为Git本地库，然后尝试将本地的Git提交到GitLab，Kaijia使用的命令是：
|
1 |
git push -u origin master |
但是Shell显示的结果却是：
error: RPC failed; result=22, HTTP code = 413
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Everything up-to-date
Kaijia看了一下GitLab这次提交没有显示出来，说明这次提交中断了。于是Kaijia搜索了一下，发现也有人报告遇到“fatal: The remote end hung up unexpectedly”错误，但是报告的错误一般都是通过SSH连接GitLab的情况，而Kaijia是通过HTTPS（禁用SSH避免安全隐患）的。最后Kaijia在GitLab的Issue Tracker上找到了一个错误报告成功解决了这个问题。
WordPress 3.5默认禁用了链接管理器功能，于是出现了WordPress测试时很多人报告链接管理器消失为Bug的情况。WordPress本地化团队还发布过一篇日志解释如何恢复链接管理器：
如果您需要该功能，请前往“仪表盘” → “插件” → “安装插件”，然后搜索“Link Manager”，来安装由“WordPress”或“nacin”开发的“Link Manager”插件以启用该功能。
其他博客也提供了更多方法，例如在主题的functions.php中增加：
|
1 |
add_filter( 'pre_option_link_manager_enabled', '__return_true' ); |
这些方法都可以实现恢复WordPress链接管理器，但是都对WordPress进行了修改。Kaijia尝试找一种可以不修改WordPress，于是对比了一下几个博客的wp-options表和新安装WordPress的wp-options表，参考了WordPress Codex文档中的提示：
As of Version 3.5, the Links Manager and blogroll are hidden for new installs and any existing WordPress installs that do not have any links. If you are upgrading from a previous version of WordPress with any active links, the Links Manager will continue to function as normal.
最后找到了最快的解决办法，只需要WordPress数据库中运行以下语句便可在不更改WordPress的情况下启用链接管理器功能：
|
1 |
UPDATE `wp_options` SET `option_value` = '1' WHERE `option_name` = 'link_manager_enabled'; |
如果使用PHPMyAdmin，只需要在wp-options表中搜索option_name为link_manager_enabled的记录，并将其值改为1即可。这样WordPress链接管理器就恢复了。
Kaijia这几天开始使用Zabbix来监控服务器的性能。一开始监控的是几台主要的机子，一直用的很不错，于是将几台不重要的服务器也托进来。这时在有一台服务器上遇到了问题，按照之前相同的配置完成之后，Zabbix Server一直提示无法访问这台服务器上的Zabbix Agent（版本是为Ubuntu 12.04源中自带的1.8.11）。Kaijia查看了一下Zabbix Server的日志，找到了错误提示：
Get value from agent failed: ZBX_TCP_READ() failed: [4] Interrupted system call
Kaijia于是Google了一下，发现也有很多人遇到了这个错误，错误提示是连接被中断，但是网上的提问好像基本没有得到解决的。
众所周知，32位的PHP函数filesize无法有效获取2GB以上大文件的文件大小，的确在古老的年代里，人们应该还没有考虑到某天会需要使用PHP读取一个2GB以上的大文件。在PHP手册中就写明了：
因为 PHP 的整数类型是有符号整型而且很多平台使用 32 位整型，对 2GB 以上的文件，一些文件系统函数可能返回无法预期的结果。
不过这个巧事却被Kaijia遇上了。这几天Kaijia在写一个使用百度网盘API的服务器数据备份工具（因为百度提供了PHP SDK，所以Kaijia使用了php-cli来运行此程序），由于百度网盘限制通过API上传2GB以上的大文件，所以上传大文件需要将文件分割，当然分割之前需要判断文件是否超过2GB，而这时却遇到了问题：PHP自带的filesize函数在遇到2～4GB大小的文件时返回了负数。导致上传经常出错。于是Kaijia Google了一下，找到了很多种方法，但是都存在缺陷，部分文件大小仍然无法正常读取。最后Kaijia通过Stack Overflow给出的一个失效链接导引回PHP手册找到了一个有效的办法。
qTranslate是一个非常有用的插件，在Kaijia之前的文章中也经常有提及。但是qTranslate会对WordPress内核作出一些改动，包括影响WordPress的正常更新。这些改进可以概括为qTranslate会将一个中文版的WordPress切换到英文，即相当于在wp-config.php中设置：
|
1 |
define('WPLANG', 'en_US'); |
这样的情况会造成每当WordPress放出新版时，系统的自动更新页面只会显示WordPress英文版的更新，而不会显示中文版的更新，并且会提示：
您将安装美式英语版本的WordPress 3.6，这可能会破坏您当前使用的翻译。
当然，这样更新也是可以的，但是更新中文版肯定是更好的，Kaijia已经处理过很多次安装有qTranslate的WordPress站点的更新，于是在这里总结一下这种情况下的更新方法。
阅读更多
终于，在升级到Firefox 23.0之后，Kaijia的Unity启动栏中出现了第一个被“拍扁了”的图标——火狐。这个新Logo在Unity启动器上只能用惨不忍睹来评价了：
Unity启动器中Firefox新旧图标比较
上一篇博文中Kaijia已经吐嘈过如何将Firefox降级到22.0版本了，但是不升级终究不是个好办法，并且Ubuntu没有提供Firefox 17.0 ESR（长期支持版本）的更新，所以升级到新版本的Firefox是不可避免的。于是Kaijia想到了一个办法，用旧版本的Firefox图标在Unity启动器中替换掉这个破坏整体感觉的新图标，这样就可以实现用的是Firefox 23.0但任务栏中显示的还是旧版的Firefox了。
- 已经载入全部文章 -
近期评论