Building the Coming Soon

关于

HFLS aka the Akademia 12′, then NUST 16′, HKU 18′, now a Blue.

学习

Proxmox多LXC容器无法分配目录变化通知问题解决

04/28/2019

今日Kaijia的Proxmox集群中有一台服务器异常不稳定,经常丢失状态,并且在执行任何操作时常常遇到错误提示:

Failed to allocate directory watch: Too many open files

检查了一下这台服务器上运行的LXC容器有30多个,当中不乏数据库、MongoDB、DA及爬虫等IO大户,然而利用lsof查看了一下当前使用的文件句柄亦无发现任何异常。

阅读更多

MySQL 8.0.15向8.0.16升级启动失败问题解决

04/28/2019

今天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/’一句。

阅读更多

LXC容器内Arch Linux升级systemd网络丢失恢复方法

07/28/2018

Kaijia一般使用Arch Linux在容器内运行一些万年(比一个红帽发行周期还长)不需要手动维护、且每次升级都不需要人工干预的软件,比如memcached,一次安装完成配置后只需设置pacman自动更新即可不必再次登录。不过最近Kaijia的Arch Linux容器却意外在重启后纷纷丢失了网络。Kaijia查阅了systemd的日志和错误报告,发现networkd组件在238版本中引入了一项变动使得在容器内网络设备无法完成配置,从而导致了容器内系统在下次重启时无法联网。当然问题发现后,随之而来的是如何将systemd恢复到正常的版本。

阅读更多

VestaCP面板载入响应缓慢问题解决

02/03/2018

今天小伙伴向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管理脚本时。

阅读更多

MySQL时间跳跃无法停止问题解决

10/19/2017

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面板迁移用户时更换目标MySQL数据库方法

10/19/2017

VestaCP的傻瓜式迁移方法对于简单示例来说非常方便,在旧新示例上分别执行v-backup-userv-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

阅读更多

编译TensorFlow 1.3 SHA256校验错误临时解决方案

09/24/2017

由于通过PIP分发TensorFlow默认没有编译SSE4.1、SSE4.2、AVX三个指令集(以及Intel新的MKL库),今天Kaijia为了发挥芯片组的最佳性能尝试了手动编译TensorFlow。按照谷歌官方的安装文档前面的配置步骤均顺利完成,直到开始利用bazel编译时Kaijia碰到了不应该出现的包括protobufllvm等数个组件下载后SHA256与期望SHA256存在差异的校验问题。

阅读更多

“/var/lib/mlocate/mlocate.db”不存在问题解决

09/24/2017

通常在一个新系统上编译大型软件时会遇到各种错误,比如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文件是不存在的。

阅读更多

APT-GET“Couldn’t create temporary file for passing config to apt-key”问题解决

08/18/2017

今天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文件。

阅读更多

邮件日志中的“UGFzc3dvcmQ6”详解

08/11/2017

今天邮箱服务器又报了内存不足,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

阅读更多

较旧文章
... 载入更多文章 ...

- 已经载入全部文章 -