云服务器上的 Arch Linux 在最近一次系统更新并手动重启后 dockerd 无法启动，journalctl 看到服务日志中的报错为 Main process exited, code=dumped, status=11/SEGV。
于是将服务器上的 /usr/bin/dockerd 与本地文件及官方包中的文件进行对比，发现文件大小均一致，但计算出的 SHA256 只有服务器上的文件不一致，说明文件已损坏。
进一步使用 journalctl 查看全量系统日志，发现大量 kernel: I/O error，推测是系统更新过程中文件写入出现问题，最终导致文件损坏。

前段时间新开了 static-binaries 仓库基于 Alpine Linux aports repository 来静态编译日常开发调试过程中常用的命令行工具，计划在各个发行版的常见版本上测试编译结果能否正常运行，于是使用 libvirt 从各发行版官方提供的 cloud image 快速创建虚拟机作为测试环境。
使用 Debian 和 CentOS 的 cloud image 创建虚拟机的过程中遇到了多个问题，例如创建 debian12-amd64 虚拟机时的 cloud-init 参数不生效，创建 debian12-arm64 虚拟机时报错 /usr/share/libvirt/cpu_map/arm_Ampere-1.xml 文件不存在，还有创建的 centos7-arm64 虚拟机在启动时报错 Synchronous Exception，尝试寻找解决方案。

4.5

还是本地搭建的 tracing-benchmark 测试环境，测试过程中观察到 jaeger 在 v1 和 v2 不同版本下提供的 metrics 不同，且都包含关于 spans 数量的统计。
根据测试结果可知高负载环境下不同版本均会主动丢弃 spans，好奇丢弃 spans 的具体数量，丢弃行为发生在 client 端还是 server 端，以及能否设置为禁止丢弃。
因此将 otel trace 的主要逻辑提取出来并进行测试，顺便观察单个 span 从创建到保存的完整流程是什么样的。

本地使用 docker 来搭建 tracing-benchmark 的测试环境，在测试过程中观察到默认的 bridge 网络下 docker-proxy 进程的 CPU 使用率甚至会高于应用容器本身。
一方面不确定 docker-proxy 的高负载对应用容器的性能测试结果会有多大影响，另一方面则是觉得单纯的 TCP 端口转发功能不应该有这么高的 CPU 使用率。
因此计划模拟并测试 docker-proxy 在高网络负载下的具体表现，以及相关替代方案的实际优化效果。

3.5

使用 chroot 命令可以改变进程的可见根目录，创建出一个 chroot jail，限制对应进程可访问到的文件，降低程序的部分安全风险。
之前编写过一个文件分享 Web 应用 share-Go，在仓库的 README.md 中给出了 run with linux chroot 的简单示例，以避免非预期的文件访问。
偶然发现该 chroot 示例中存在几个隐藏问题，主要涉及到 Golang 程序的外部环境依赖，就顺便整理记录下来。

根据公司相关要求，把自己的主机换成了公司的笔记本。在 Windows 11 上测试了 Hyper-V 虚拟机和 WSL 2，感觉使用 vscode remote 搭建开发环境还是不太方便。
与相关部门进行沟通后，确认公司允许使用 Ubuntu Desktop 作为本地开发环境，于是将笔记本重装为 Kubuntu，期望能接近在 Arch Linux 上的 KDE 使用体验。
测试 Kubuntu 的过程中发现笔记本 CPU 的最大频率明显比 Windows 11 上的低，因此尝试排查具体原因，寻找解决办法。

新功能上线后 Nginx 的日志监控频繁上报某类请求 502 Bad Gateway，但在对应的 Golang 后端服务日志中却没有找到任何异常。
抓取请求参数在测试环境复现后，发现异常请求在 Golang 后端服务日志中会正常打印为 200 OK，与其他正常请求无区别。
根据 Nginx 日志中的请求时间推测，是 Golang 后端服务在请求超过 60 秒后主动关闭了连接，但并没有处理相关超时异常。

2.5