Tag Archives: systemd

故障现象 2021年1月20日接到通知，要把systemd升级到219-73.tl2.10或以上、并把rsyslog一起升级，以修复/var/log/messages无日志内容的bug。经实验，发现使用yum升级两个软件包之后，systemd-logind的可执行文件也被更新，导致该服务处于原可执行文件已删除的状态，所以我提议，在升级步骤中增加重启systemd-logind服务的动作。在Ansible playbook里，因为不能表达“大于219-73.tl2.10“这种范围型版本号，所以就明确指定systemd的版本为当前yum能自动安装到的最新版本219-78.tl2.3 2月1日由同事执行更新操作之后，大部分节点都正常工作，但有两台发生重启事故，另有一台上的 35777 systemd-login进程占内存高达4～6G。这三台恰好是一组elasticsearch的三台master节点，均为C8机型，即16G内存的kubernetes容器。 检查修复 我尝试重启剩余的这台的system-logind，发现新进程3851号仍然占6G内存。查看/proc/3851/smaps，该区域为heap；用pmap命令查看，显示为[ anon ]。对比正常服务器的同一个内存区域，才244K而已。 检查三台故障机及其宿主机的日志，发现大量oom记录，其中重启的两台所属宿主机的kubelet也发生故障重启：Feb 1 18:43:50 TENCENT64 kubelet: panic: runtime error: invalid memory address or nil pointer dereference 先gcore一份保留故障现场。由于操作系统组同事不登录上来观察，仅提供重启进程等建议，我只好自己做检查。根据建议，检查了dbus服务（dbus-daemon进程），发现也是可执行文件被删除的状态。检查yum日志，发现在去年6月升级了dbus包，但是服务进程是3月5日启动的，也就是升级包的时候并没有重启这个服务。再次尝试重启systemd-logind，新进程14278号，发现用内存VmPeak: 5270484 kB；但是过了一会儿再观察，发现增加到了VmPeak: 6599828 kB。这说明内存的增长是一个过程，虽然增长比较快，但并不是一下子就6G的。于是我决定strace一下它。 先关闭systemd-logind服务。使用命令strace -ff -s 1000 -p 1挂在systemd主进程上做跟踪，并用-o参数把多个进程的跟踪记录分别写在文件里。然后启动systemd-logind服务。这样，strace可以跟踪到 1号进程clone+execv执行systemd-logind的瞬间，以及systemd-login最开头的行为。检查systemd-login的strace记录，发现大量访问 /run/systemd/session/ 目录下面文件的动作。检查该目录，发现大量残留文件。搜索，发现 https://www.jianshu.com/p/343a072e2521 … Continue reading →