一次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的任何版本了

飞书机器人吐槽

markdown的消息

markdown消息中的图片必须要要先上传到飞书的后台上去,拿到image_key, 然后才能显示,否则,消息发送给服务器,服务器直接无法构造就返回一个错误,消息也不会发送。 我本来以为这个是客户端这边支持的,看来这个消息格式的解析是服务器进行的。叮叮的则无问题,只要是可以访问的路径就行。这方面叮叮弄的比较好,比飞书的阉割版markdown消息 要强很多,毕竟不是所有的文件都可以随意的扔到别人家的服务器上的。

markdown嵌套的图片消息,没办法设置大小,或者缩放,图片也以居中裁剪的方式显示,导致消息列表中的图片显示不完整。对二维码的显示尤为不友好。如果要想显示完整,或者对图片 进行缩放之类的,或者使用img消息,这样必然会使完整的markdown消息需要进行分部分切割,处理起来就不连贯了。

javascript 神奇的array类型

猜测以下代码的输出

let test = {};

function func1(test) {
    test.obj = test.obj || [];
}

function func2(test) {
    test.obj['test'] = test.obj['test'] || {ok:true};
}

func1(test);
func2(test);
console.log("test1==", test); // { obj: [ test: { ok: true } ] }
console.log("test2==", JSON.stringify(test)); // {"obj":[]}
console.log("test3==", JSON.stringify(test.obj['test'])); //{"ok":true}
  1. 默认情况下,object日志输出的时候,会往下几级,输出结果尽可能的完整,所以可以完整输出
  2. array类型支持字符串之类的作为下标索引,但JSON.stringify的时候,会被忽略,所以输出的是个空的数组
  3. 数据还是存在的