今日Kaijia的Proxmox集群中有一台服务器异常不稳定，经常丢失状态，并且在执行任何操作时常常遇到错误提示：
Failed to allocate directory watch: Too many open files
检查了一下这台服务器上运行的LXC容器有30多个，当中不乏数据库、MongoDB、DA及爬虫等IO大户，然而利用lsof查看了一下当前使用的文件句柄亦无发现任何异常。
今天Kaijia日常（已经算是月常了）从Oracle的官方源更新MySQL之后发现MySQL无法正常启动了，查看了一下/var/log/mysql.log也异常单一。
2019-04-28T02:59:39.881846Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.16) starting as process 384
2019-04-28T02:59:50.800045Z 4 [System] [MY-013381] [Server] Server upgrade from ‘80015’ to ‘80016’ started.
2019-04-28T02:59:52.461014Z 4 [ERROR] [MY-013384] [Server] Could not create server upgrade info file at ‘/var/lib/mysql/’.
2019-04-28T02:59:52.468088Z 0 [ERROR] [MY-013380] [Server] Failed to upgrade server.
2019-04-28T02:59:52.468307Z 0 [ERROR] [MY-010119] [Server] Aborting
2019-04-28T02:59:54.080113Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.16) MySQL Community Server – GPL.
早前Oracle家出错都能打印出一长串错误日志，这次仅仅留下有Could not create server upgrade info file at ‘/var/lib/mysql/’一句。
Kaijia一般使用Arch Linux在容器内运行一些万年（比一个红帽发行周期还长）不需要手动维护、且每次升级都不需要人工干预的软件，比如memcached，一次安装完成配置后只需设置pacman自动更新即可不必再次登录。不过最近Kaijia的Arch Linux容器却意外在重启后纷纷丢失了网络。Kaijia查阅了systemd的日志和错误报告，发现networkd组件在238版本中引入了一项变动使得在容器内网络设备无法完成配置，从而导致了容器内系统在下次重启时无法联网。当然问题发现后，随之而来的是如何将systemd恢复到正常的版本。
今天小伙伴向Kaijia反映万年没有动的VestaCP面板突然间响应缓慢，Kaijia登录检查发现每次点击VestaCP面板中任意功能，均需要等待3~5秒时间才能响应，而同时间服务器并无高负载、高IO情况，VestaCP管理下的网页亦可飞速打开。
为了找到延时原因，Kaijia在/usr/local/vesta/php/etc/php-fpm.conf开启了VestaCP的慢执行日志（slow log），获得以下记录：
[03-Feb-2018 23:00:54] [pool www] pid 2721
script_filename = /usr/local/vesta/web//list/web/index.php
[0x00007f8ead529798] exec() /usr/local/vesta/web/list/web/index.php:9[03-Feb-2018 23:01:03] [pool www] pid 2721
script_filename = /usr/local/vesta/web//list/web/index.php
[0x00007f8ead529708] shell_exec() /usr/local/vesta/web/list/web/index.php:12
再返回查看代码，显示所有的慢执行均发生在exec()和shell_exec()函数调用VestaCP CLI管理脚本时。
Kaijia昨天安装新VestaCP服务器后遇到了罕见MySQL无法退出重启的问题。通常情况下执行 service mysql stop 时MySQL会立即停止，在储存语料、数据的MySQL实例上最多也就需要半分钟将缓存写回硬盘后停止，然而Kaijia这台全新安装的MySQL服务器在发送退出命令后始终没有任何响应，直到十分钟后才会由systemctl超时杀死进程。
围观了一下MySQL日志，提示了未能停止的原因是在等待page_cleaner完成清理缓冲池：
2017-10-18T12:36:44.721465Z 0 [Note] InnoDB: Buffer pool(s) dump completed at 171018 20:36:44
2017-10-18T12:37:45.372406Z 0 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool
VestaCP的傻瓜式迁移方法对于简单示例来说非常方便，在旧新示例上分别执行v-backup-user和v-restore-user命令即可完成，这一过程假定了两台服务器上所有的配置均为默认安装，因此在对VestaCP配置作出过调整的情况下会迁移则会出现错误。
Kaijia昨天一直运行VestaCP的服务器到期，考虑网络因素决定将VestaCP迁移到阿里云中。考虑到扩展需求（吃内存的MySQL 5.7），Kaijia决定利用两台1G内存的云服务器，第一台运行除了MySQL以外的其他服务，第二台（设定域名为mysql.kaijia.me）单独运行MySQL，并将其添加为VestaCP的远程MySQL服务器。这样的配置与虚拟主机商采用的策略相同，但因此调整，在将VestaCP用户迁移到新服务器时便会出现问题：
[email protected]:~# v-restore-user kaijia kaijia.2017-10-18.tar
— DB —
2017-10-18 21:31:14 kaijia_example
Error: mysql config parsing failed
由于通过PIP分发TensorFlow默认没有编译SSE4.1、SSE4.2、AVX三个指令集（以及Intel新的MKL库），今天Kaijia为了发挥芯片组的最佳性能尝试了手动编译TensorFlow。按照谷歌官方的安装文档前面的配置步骤均顺利完成，直到开始利用bazel编译时Kaijia碰到了不应该出现的包括protobuf和llvm等数个组件下载后SHA256与期望SHA256存在差异的校验问题。
通常在一个新系统上编译大型软件时会遇到各种错误，比如Kaijia在全新的LXC容器内编译TensorFlow时遇到的：
locate: can not stat () `/var/lib/mlocate/mlocate.db’: No such file or directory
mlocate.db文件是用于查找文件的locate命令的数据库，相当于Windows系统下的搜索索引功能，此数据库每天定时利用CRON脚本/etc/cron.daily/mlocate进行增量更新，避免每次重新建立索引。在一个全新的系统下，通常每日CRON并未有执行，因此在系统刚安装完成至第二天0点前的时间里mlocate.db文件是不存在的。
今天Kaijia登上一台万年没动的服务器，跑了一下APT更新，遇到了一个最有意思的问题：
Err:4 http://ftp.debian.org/debian stretch Release.gpg
Couldn’t create temporary file /tmp/apt.conf.aBDdBI for passing config to apt-key
不同于以往理论上APT服务器离线、Key过期出错等情况，这次的问题是无法将配置文件传递给apt-key。
简单查阅了一下资料，显示apt-key等等实际上并不是直接使用/etc/apt/apt.conf配置文件，而是每次执行操作的时候将配置文件复制到临时文件夹下（以做一些修改等等）。虽然apt-get需要Root权限才能执行，但执行过程中的子任务，例如调用apt-key时，是交给_apt这一用户完成的。所以实际上问题很简单，既是目录对_apt用户缺少了权限，因此无法创建临时的apt.conf文件。
今天邮箱服务器又报了内存不足，Kaijia思考平常也并没有什么使用量，肯定是有外部因素，看了一下/var/log/mail.log日志，办天内出现了30万条错误类似如下的错误：
Aug 11 16:08:14 mta postfix/smtpd[1650]: connect from unknown[IP]
Aug 11 16:08:21 mta postfix/smtpd[1593]: warning: unknown[IP]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
Aug 11 16:08:21 mta postfix/smtpd[1593]: lost connection after AUTH from unknown[IP]
Aug 11 16:08:21 mta postfix/smtpd[1593]: disconnect from unknown[IP] ehlo=1 auth=0/1 commands=1/2
- 已经载入全部文章 -
近期评论