BugFix: Blog 升级、安装插件期间访问出错

USTC Blog 升级、安装插件期间,访问首页会提示出错。原因是 WordPress 进行升级、安装插件等操作时,会生成 .maintenance 文件,wp-includes/load.php 会试图 include 这个文件以检查其存在性。为了保证安全,USTC Blog 禁止 include 非 .php 后缀的文件。因此我们将 .maintenance 修改成 .maintenance.php 以绕过此限制。相关 commit:

http://gitlab.lug.ustc.edu.cn/ustc-blog/wordpress/commit/4537059a91aea17a6d85151293b6a35c668fa6ff

感谢 Moqi Lee 同学的 bug 反馈。

9月7日 blog 数据库 OOM kill

9月7日16:30,blog 数据库(mysqld)被 OOM kill。故障在 19:00 左右恢复。

恢复方法是先后重启 mysql 和 php-sandbox 服务。php-sandbox 有一个已知的 bug,mysql 重启后不会自动重连,因此 mysql 重启后必须重启 php-sandbox 服务。

本次故障是内存溢出引起的,当天 14:30 已经收到 monit 的邮件报警,但当时唯一接收报警的 boj 没打开数据流量,没收到邮件,酿成服务中断的悲剧。我们今后将让服务器维护小组的更多人收到报警。

PXE 支持 IPv6

pxe.ustc.edu.cn 长久以来不支持 IPv6 的问题于今天被解决。

之前 /etc/network/interfaces 中已配置 2001:da8:d800:931::94 这个地址,不过没有生效。 现在已绑定到网卡上了。

/etc/lighttpd/lighttpd.conf 中增加了一行:
server.use-ipv6 = “enable”

之后 /etc/init.d/lighttpd restart 了。

一共就这些操作。

— tux, USTC PXE Maintainer

blog 启用 monit 监控报警

由于前些天 blog.ustc.edu.cn 服务器多次发生 OOM Kill 等异常情况,我们使用 monit 对系统行为和各进程进行了监控和报警。这是 LUG 网络服务首次部署较为细粒度的监控和报警。

monit 配置文件参考:http://gitlab.lug.ustc.edu.cn/boj/blog-monit-config/tree/master

希望 mirrors 等其他服务的维护者也部署 monit 之类的报警机制。

科大开源软件镜像发生磁盘故障

2013年8月31日 11:06,科大开源软件镜像(mirrors.ustc.edu.cn)发生磁盘故障。磁盘 sda 从系统中突然消失。sda 上有 mirrors 主系统(mirrors-main)的根分区、各 LXC 虚拟机系统的根分区,sda 的消失导致 mirrors 的所有服务立即中断。

问题发生一小时后的 12:08,Stephen Zhang 在邮件列表发帖说 mirrors 挂了。收到邮件后,我们检查了服务监控系统,发现学校短信平台也很不巧地挂掉了,因此没有在第一时间收到报警短信。我们登录到 mirrors-base(mirrors-main 是 Xen 虚拟机,mirrors-base 是 Xen Domain0),发现 dmesg 中有同样的磁盘错误信息,/dev/sda 不见了。据此判断是磁盘故障。

由于此问题无法快速解决,我们采用以往的方法(所谓“启动应急预案”),将 mirrors 的 DNS 设置别名为 backup.mirrors.ustc.edu.cn,它解析到 lug.ustc.edu.cn 服务器,显示一个临时错误页,并把大部分源 HTTP 重定向到国内其他开源软件镜像。

随后,我们把 /etc 备份到其他机器上,挽救了一些尚在缓存内的配置文件。我们重新扫描了 SCSI 总线,未发现新设备。确认主管机房的张运动老师在校后,在学校的 bible 去了网络中心机房。张运动老师还说学校几百台服务器依赖 CentOS 来装软件包,让我们一定把 CentOS 源维护好。据去年统计,校内流量仅占 mirrors 总流量的1%,因此每次 mirrors 挂机,都可能影响数以万计的服务器和 PC,对此我们深感愧疚。

重新拔插硬盘、物理重启 mirrors 数次,包括使用不带 Xen 的内核,仍未在系统里发现丢失的那块磁盘。在 RAID 控制界面,发现有两块磁盘报 PD Missing 错误。我们尚未找到相关技术资料。

2013-08-31

目前 mirrors-base(Xen Domain0)仍然在正常运行,因其根文件系统在 sdc 上。mirrors-main 连同 LXC 虚拟机系统的根分区连同那块硬盘,已经消失了。我们怀疑并不是硬盘损坏,因为两块硬盘是硬 RAID1,同时损坏的概率微乎其微;怀疑是 RAID 卡损坏,或者主板上接线松了。

本次故障由于涉及硬件问题,恢复时间未知。我们对此带来的不便深表歉意。

USTC Blog 服务8月22日晚间中断

8月22日晚间,USTC Blog 服务出现乱码、显示0个用户等问题。

此问题由 Hao Wang 在邮件列表里报告(http://archive.lug.ustc.edu.cn/2013-August/012242.html)。

bible 在第一时间修复了这个问题(http://archive.lug.ustc.edu.cn/2013-August/012244.html

boj 给出了此次故障的一些技术信息(http://archive.lug.ustc.edu.cn/2013-August/012248.html

当时 blog 服务器上没有运行特别占用资源的服务,而 freeshell 上运行了批量解析域名的脚本,resolver 是 blog,故有可能是由于 blog 上自建的 BIND9 recursor(进程名:named)占用了过多内存。之前已经设置了 BIND9 recursor 缓存限制为 512M,因此不知道是什么原因。总之,这种不熟悉的服务最好不要在生产服务器上搭建。

这次还揭露一个问题,服务器报警不够全面。早先的报警是”黑盒测试”,在 HTTP response 不包含给定字符串时触发,这次首页和我的个人博客没有明显故障,是发现不了的。因为硬盘满而出故障那次之后,还加入了磁盘报警,这是第一个”白盒测试”,不过这次没派上用场。应该再加一种白盒测试,tail -f syslog,一旦出现某些感兴趣的关键词就报警。