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用户迁移到新服务器时便会出现问题：
root@kaijia:~# 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
在大约4年又6个月之后，iPlacard公开了。其实Kaijia很早就应该公开了，因为在过去的几年陆陆续续近1400个提交，该实现的功能都已经实现了，现在还在Feature Request里面的除了允许主席收作业一项外大多都是在线聊天一类的请求，因此可以说是基本开发见顶了。原先的计划是当市场出现了同等水平的系统时就公开，现在看来没有熬到这天（蛤）。
iPlacard的代码可以访问 http://iplacard.com 或者直接GitHub仓库 https://github.com/fengkaijia/iplacard 获取。接下来的几天，Kaijia将在这篇文章里简单介绍几个iPlacard使用的注意事项。 阅读更多
昨天收到阿里云的通知，Kaijia一台青岛机房2年半前创建的阿里云实例（可用区B）需要迁移到新的物理机上（即从两三年前最早的系列I升级到现在的系列III）。毕竟是性能升级，于是Kaijia很高兴得预约了吃螃蟹，结果升级完成了之后，实例就无法再次连接上了。
Kaijia从管理面板终端登录，发现执行ifconfig并无原有的eth0和eth1，而手动激活网卡时则会出现错误：
# ifup -v eth0
cannot find device “eth0”
Dell XPS 13系列自9343以来的设计堪称经典，但毕竟是超薄机型，对电路设计的要求等原因导致一直以来XPS 13都伴有着各种稀奇古怪的硬件问题。其中之一便是Kaijia使用一年以来经常碰到的触摸板假死/光标漂移问题。重复此问题需要满足几个条件：1、XPS未充电；2、XPS未放平（例如放在教室的折叠式桌板上）；3、XPS使用超过5分钟（且略烫）；4、手指有汗渍。此时触摸板非常容易偶发假死——手指在移动触摸板上移动但光标却无响应，换用其他手指或按下触摸板左键移动时则可正常响应——或光标在移动过程中上下漂移。Kaijia与内地和香港的戴尔技术支持均有联系，但都无法测定该问题的原因（因为重复实验相当困难）。
- 已经载入全部文章 -
近期评论