一次fetchmail获取gmail异常的处理

我使用的是mailu来处理所有邮件的,内部使用fetchmail获取gmail,从上个月的某天开始,突然发现fetchmail无法获取gmail中的邮件了。 报错如下:

fetchmail: imap.gmail.com: fetchmail: System error during SSL_connect(): handshake failed at protocol or connection level.

各种测试都不可以。最后发现将*关了就好了,最后添加了一条规则并置于较高的优先级解决了。看来gmail和这个有点不兼容

一次服务器硬盘故障处理

首先要说的一点,因为服务器的SAS硬盘比较贵,因此我使用了普通的SATA硬盘,为了更大的容量和较快的速度,我用了4块硬盘,组成raid 10,这样本身的目的是在兼顾安全的同时,稍微增加些速度。4块硬盘raid10大概 相当于相同容量的一块SAS硬盘,考虑到一般同时购买多块SAS硬盘,这个方案相对便宜些,当然,缺点也很明显,SATA的数据安全性不如SAS,读写速度也只有SAS的一半。以我的方案,大致相当于单块的SAS的读写速度。 运行的数据也仅仅为日志数据,非绝对重要数据。

之前一直运行正常。前两天突然发现一直出现读写速度很慢,从数据库落后的越来越多。经过检查,删除一个文件有时候需要几十秒到几分钟,甚至列出目录都非常的慢。我不清楚是否是btrfs文件系统的事情。 因此,第一天着重检查这块。不过用的是最新的系统内核了(ubuntu 22.04 kernel: 5.15.0.57), 最后也没有检查出个所以然。第二天准备干脆把老的SAS硬盘装上,然后把SATA当普通的硬盘来用,就 准备重做。重做之前,准备把原来的数据,复制到移动硬盘中,如果移动硬盘速度可以的话,直接切换到已经硬盘也是我的一个选项,过年前不想太折腾乐。结果,移动硬盘的读写,只能通过usb2.0,最快30MB。 这直接放弃了切换移动硬盘了。然后就是第二个选项,重做系统,用了很久的时间,忍受着30MB的写入,动不动就造成整个系统卡住的btrfs系统,用了大半天的时间,终于将最需要的数据复制到移动硬盘。 然后切换硬盘,重装系统。最后再复制回数据,从重装系统到完工,折腾了4个小时。

后来复盘处理流程,其实并不需要将数据复制到移动硬盘上,因为老的5x300GB的sas硬盘重新安装系统,与原有的4x2T的sata硬盘并不冲突,完全可以在raid中新建一个5x300GB的raid,然后安装系统。 安装完之后,再挂载sata,复制数据,这样会快很多,估计从最初到最终2个小时就处理完成了。以后做事情之前,还是要先列出流程,优化一下,然后再实施。磨刀不误砍柴工嘛

Nexus 5 刷lineageos > 17.1

太久没折腾我的nexus 5手机了。最近因为要用它折腾点东西,系统版本太老。就决定刷个新的吧。 刚开始选定lineageos 18,发现即使使用最新的twrp recovery刷机的时候也会报告下面的错误:

E1001: Failed to update system image.
Updater process ended with ERROR: 1

网上的各种方法,/cache/recovery, chmod 755等都无效。最后发现可能是system分区太小的缘故。

于是就刷入twrp-3.7.0_9-HH.R.17.img的recovery,在recovery中的终端中使用下面的命令,将 system扩大到1.4GB(我刚开始在adb shell中操作的,貌似成功不了,在手机的终端中操作,一次搞定)

hh_repart -m

然后就可以刷入大于17.1的任何版本了