登录缓慢为哪般？

最新推荐文章于 2025-04-28 16:29:54 发布

原创最新推荐文章于 2025-04-28 16:29:54 发布 · 1.1k 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#docker #linux #运维 #kubernetes #容器

上周在给GDK8升级系统镜像时，测试小伙伴发现，输入用户名和密码后，要等30秒才进入桌面。

9:47:00 图形界面输入密码点击登录

9:47:35 图形界面显示桌面图标

开机时间是影响用户体验的关键指标，这个速度比老的镜像慢太多，是不可以接受的。

系统日志

对于这样的问题，通常是systemd所领导的系统初始化过程发生故障，比如启动某个服务时发生意外。

定位这样的问题，首先是查看系统日志，常用的命令就是：

journalctl --no-pager

日志很长，但因为是按时间排列的，所以很容易按小伙伴记录的时间找到下面这条线索：

May 22 09:47:30 gdk8 dbus-daemon[470]: [system] Failed to activate service 'org.freedesktop.UPower': timed out (service_start_timeout=25000ms)

这条日志的时间是5月22日早上9：47：30秒，距离小伙伴输入密码后30秒，日志的内容是没能成功激活'org.freedesktop.UPower'服务，冒号后面是原因：超时，括号里里面是启动这个服务的超时参数25000毫秒，也就是25秒。

看来系统在启动这个服务时遇到意外，等待25秒后，也没有收到这个服务的成功消息，于是系统报告超时错误。

这个服务是谁呢？全名叫org.freedesktop.UPower，一般简称为upower。使用如下命令可以观察upower服务的状态。

systemctl status upower

geduer@gdk8sudo systemctl status  upower
× upower.service - Daemon for power management
     Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2024-05-22 10:03:04 CST; 1min 58s ago
       Docs: man:upowerd(8)
    Process: 1715 ExecStart=/usr/libexec/upowerd (code=exited, status=217/USER)
   Main PID: 1715 (code=exited, status=217/USER)
        CPU: 116ms


May 22 10:03:04 gdk8 systemd[1]: upower.service: Scheduled restart job, restart counter is at 5.
May 22 10:03:04 gdk8 systemd[1]: upower.service: Start request repeated too quickly.
May 22 10:03:04 gdk8 systemd[1]: upower.service: Failed with result 'exit-code'.
May 22 10:03:04 gdk8 systemd[1]: Failed to start upower.service - Daemon for power management.

使用以物为师的方法论，观察没有问题的幽兰系统，这个服务存在，而且健康运行：

geduer@ulan:~$ systemctl status upower
● upower.service - Daemon for power management
     Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled; preset: enabled)
     Active: active (running) since Tue 2024-05-22 10:09:07 CST; 22min ago
       Docs: man:upowerd(8)
   Main PID: 1230 (upowerd)
      Tasks: 4 (limit: 18741)
     Memory: 2.9M ()
        CPU: 511ms
     CGroup: /system.slice/upower.service
             └─1230 /usr/libexec/upowerd

知己知彼

接下来的任务是要调查这个upower服务为何没有能启动成功。在freedesktop的官网可以看到upower的详细文档。

https://upower.freedesktop.org/docs/

根据这个文档可以知道upower服务的接口，主要功能等信息。

浏览一番upower的文档后，我对它有了几分亲近感。

上调试器

下一步我准备上gdb，使用如下命令行让upower服务在gdb中运行。

sudo gdb --args /usr/libexec/upowerd -rvd

其中的选项d代表启用调试模式，选项v代表verbose，打印丰富信息，选项r代表用这个服务替代已经运行的实例。

gdb启动后，执行r命令，让upower在调试器下运行。

[New Thread 0x7ff6f560a0 (LWP 1314)]
[New Thread 0x7ff67460a0 (LWP 1315)]
[New Thread 0x7ff5f360a0 (LWP 1316)]
TI:11:19:14     Acquired inhibitor lock (7, delay)
[New Thread 0x7ff57260a0 (LWP 1317)]
TI:11:19:14     Starting upowerd version 1.90.3

upower代码里有一组变量：debug和verbose，它们与命令选项d和v是对应的。

gboolean debug = FALSE;
  gboolean verbose = FALSE;

同时打开debug和verbose后，可以看到upower在运行时输出大量调试信息。

浏览调试信息，下面这条引起了我的注意：

upower.service: Failed to set up user namespacing: Invalid argument

这条信息包含明确的失败，而且失败的原因是“没有能设置用户命名空间”。

顺着这条信息追查，用户命名空间是与容器技术相关的内核功能。在幽兰上观察，这个功能是动态开启的。

而在gdk8上观察，这个选项没有开：

geduer@gdk8:/proc$ zcat config.gz | grep CONFIG_USER_NS

# CONFIG_USER_NS is not set

找打这个线索后，我立刻安排小伙伴修改内核选项，增加CONFIG_USER_NS支持。

换上新的内核后，果然登录速度大幅度提高，问题解决了。

附录：upower进程中的模块列表：

(gdb) info shared
From                To                  Syms Read   Shared Object Library
0x0000007ff7fbedc0  0x0000007ff7fdae70  Yes         /lib/ld-linux-aarch64.so.1
0x0000007ff7f889b0  0x0000007ff7f97010  Yes (*)     /lib/aarch64-linux-gnu/libupower-glib.so.3
0x0000007ff7e1eff0  0x0000007ff7ec447c  Yes (*)     /lib/aarch64-linux-gnu/libglib-2.0.so.0
0x0000007ff7d806c0  0x0000007ff7db93f0  Yes (*)     /lib/aarch64-linux-gnu/libgobject-2.0.so.0
0x0000007ff7b9d5c0  0x0000007ff7cc272c  Yes (*)     /lib/aarch64-linux-gnu/libgio-2.0.so.0
0x0000007ff7b33dc0  0x0000007ff7b37e0c  Yes (*)     /lib/aarch64-linux-gnu/libgudev-1.0.so.0
0x0000007ff7ae8570  0x0000007ff7afeb28  Yes (*)     /lib/aarch64-linux-gnu/libimobiledevice-1.0.so.6
0x0000007ff7aa2c60  0x0000007ff7ab2518  Yes (*)     /lib/aarch64-linux-gnu/libplist-2.0.so.4
0x0000007ff7907d00  0x0000007ff7a241f0  Yes         /lib/aarch64-linux-gnu/libc.so.6
0x0000007ff783cb40  0x0000007ff7885930  Yes         /lib/aarch64-linux-gnu/libm.so.6
0x0000007ff7781fa0  0x0000007ff77e095c  Yes (*)     /lib/aarch64-linux-gnu/libpcre2-8.so.0
0x0000007ff7751a80  0x0000007ff7756bcc  Yes (*)     /lib/aarch64-linux-gnu/libffi.so.8
0x0000007ff77213a0  0x0000007ff7722418  Yes (*)     /lib/aarch64-linux-gnu/libgmodule-2.0.so.0
0x0000007ff76e2100  0x0000007ff76f2aa0  Yes (*)     /lib/aarch64-linux-gnu/libz.so.1
0x0000007ff7679270  0x0000007ff76aaaf8  Yes (*)     /lib/aarch64-linux-gnu/libmount.so.1
0x0000007ff7626840  0x0000007ff7643474  Yes (*)     /lib/aarch64-linux-gnu/libselinux.so.1
0x0000007ff75c56e0  0x0000007ff75e5168  Yes (*)     /lib/aarch64-linux-gnu/libudev.so.1
0x0000007ff7510280  0x0000007ff756f290  Yes (*)     /lib/aarch64-linux-gnu/libssl.so.3
0x0000007ff7124000  0x0000007ff737cf7c  Yes (*)     /lib/aarch64-linux-gnu/libcrypto.so.3
0x0000007ff7042200  0x0000007ff7046a74  Yes (*)     /lib/aarch64-linux-gnu/libusbmuxd-2.0.so.6
0x0000007ff6fe7380  0x0000007ff700a280  Yes (*)     /lib/aarch64-linux-gnu/libblkid.so.1
0x0000007ff6fb2df0  0x0000007ff6fb815c  Yes (*)     /lib/aarch64-linux-gnu/libcap.so.2

软件世界，问题很多，错综复杂，而且每个问题都不一样，但是以调试器为核心的调试方法是大有规律可循的。LINUX研习班上海站将在本周末举行，三天时间，面对面交流，每人一套GDK8套件+挥码枪硬件调试器，上调试器，看活代码，既学操作系统原理，又学调试器和20多种重要工具，一举多得，还有少量席位，错过要等明年了。

（写文章很辛苦，恳请各位读者点击“在看”，也欢迎转发）

*************************************************

正心诚意，格物致知，以人文情怀审视软件，以软件技术改变人生

扫描下方二维码或者在微信中搜索“盛格塾”小程序，可以阅读更多文章和有声读物