我正在运行 Ubuntu 20.04.5 LTS 并使用 gnome-classic 桌面(因为我坚持自己的方式)。当我最初登录时,我总是注意到 dbus-daemon 占用了几分钟的高 CPU,但它总是会稳定到可接受的水平。然而,在过去的几天里,dbus-daemon 和 system-udevd 一直占 CPU 的 50%,并且在笔记本电脑运行时没有稳定下来,导致风扇不断运行。
我运行了dbus-monitor --system
一个非常快速的消息假脱机运行,如下面的摘录:
signal time=1676894325.355898 sender=org.freedesktop.DBus -> destination=:1.245 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
string ":1.245"
signal time=1676894325.365912 sender=:1.1 -> destination=(null destination) serial=4880989 path=/org/freedesktop/systemd1/unit/sys_2ddevices_2dvirtual_2dblock_2ddm_5cx2d2_2edevice; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.systemd1.Device"
array [
dict entry(
string "SysFSPath"
variant string "/sys/devices/virtual/block/dm-2"
)
]
array [
]
signal time=1676894325.366042 sender=:1.1 -> destination=(null destination) serial=4880990 path=/org/freedesktop/systemd1/unit/sys_2ddevices_2dvirtual_2dblock_2ddm_5cx2d2_2edevice; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.systemd1.Unit"
array [
dict entry(
string "ActiveState"
variant string "active"
)
dict entry(
string "SubState"
variant string "plugged"
)
dict entry(
string "StateChangeTimestamp"
variant uint64 1676892339266329
)
dict entry(
string "StateChangeTimestampMonotonic"
variant uint64 19734942
)
dict entry(
string "InactiveExitTimestamp"
variant uint64 1676892339266329
)
dict entry(
string "InactiveExitTimestampMonotonic"
variant uint64 19734942
)
dict entry(
string "ActiveEnterTimestamp"
variant uint64 1676892339266329
)
dict entry(
string "ActiveEnterTimestampMonotonic"
variant uint64 19734942
)
dict entry(
string "ActiveExitTimestamp"
variant uint64 0
)
dict entry(
string "ActiveExitTimestampMonotonic"
variant uint64 0
)
dict entry(
string "InactiveEnterTimestamp"
variant uint64 0
)
dict entry(
string "InactiveEnterTimestampMonotonic"
variant uint64 0
)
dict entry(
string "Job"
variant struct {
uint32 0
object path "/"
}
)
dict entry(
string "ConditionResult"
variant boolean false
)
dict entry(
string "AssertResult"
variant boolean false
)
dict entry(
string "ConditionTimestamp"
variant uint64 0
)
dict entry(
string "ConditionTimestampMonotonic"
variant uint64 0
)
dict entry(
string "AssertTimestamp"
variant uint64 0
)
dict entry(
string "AssertTimestampMonotonic"
variant uint64 0
)
dict entry(
string "InvocationID"
variant array of bytes [
4c 6f ff 28 3e 58 4e 6e 81 82 b3 1c 0c 83 82 3b
]
)
]
array [
string "Conditions"
string "Asserts"
]
signal time=1676894325.366191 sender=:1.1 -> destination=(null destination) serial=4880991 path=/org/freedesktop/systemd1/unit/dev_2ddm_5cx2d2_2edevice; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.systemd1.Device"
array [
dict entry(
string "SysFSPath"
variant string "/sys/devices/virtual/block/dm-2"
)
]
array [
]
signal time=1676894325.366431 sender=:1.1 -> destination=(null destination) serial=4880992 path=/org/freedesktop/systemd1/unit/dev_2ddm_5cx2d2_2edevice; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
string "org.freedesktop.systemd1.Unit"
array [
dict entry(
string "ActiveState"
variant string "active"
)
dict entry(
string "SubState"
variant string "plugged"
)
dict entry(
string "StateChangeTimestamp"
variant uint64 1676892339266328
)
dict entry(
string "StateChangeTimestampMonotonic"
variant uint64 19734941
)
dict entry(
string "InactiveExitTimestamp"
variant uint64 1676892339266328
)
dict entry(
string "InactiveExitTimestampMonotonic"
variant uint64 19734941
)
dict entry(
string "ActiveEnterTimestamp"
variant uint64 1676892339266328
)
dict entry(
string "ActiveEnterTimestampMonotonic"
variant uint64 19734941
)
dict entry(
string "ActiveExitTimestamp"
variant uint64 0
)
dict entry(
string "ActiveExitTimestampMonotonic"
variant uint64 0
)
dict entry(
string "InactiveEnterTimestamp"
variant uint64 0
)
dict entry(
string "InactiveEnterTimestampMonotonic"
variant uint64 0
)
dict entry(
string "Job"
variant struct {
uint32 0
object path "/"
}
)
dict entry(
string "ConditionResult"
variant boolean false
)
dict entry(
string "AssertResult"
variant boolean false
)
dict entry(
string "ConditionTimestamp"
variant uint64 0
)
dict entry(
string "ConditionTimestampMonotonic"
variant uint64 0
)
dict entry(
string "AssertTimestamp"
variant uint64 0
)
dict entry(
string "AssertTimestampMonotonic"
variant uint64 0
)
dict entry(
string "InvocationID"
variant array of bytes [
0c b8 d1 90 42 3e 45 b6 88 f3 71 6e 66 1e 83 c5
]
)
]
array [
string "Conditions"
string "Asserts"
]
运行udevadm monitor
给出了类似的消息流,虽然不是那么快,如下所示:
KERNEL[2188.932041] change /devices/virtual/block/dm-2 (block)
UDEV [2188.940914] change /devices/virtual/block/dm-2 (block)
KERNEL[2188.945441] change /devices/virtual/block/dm-2 (block)
UDEV [2188.957689] change /devices/virtual/block/dm-2 (block)
KERNEL[2188.961225] change /devices/virtual/block/dm-2 (block)
UDEV [2188.969813] change /devices/virtual/block/dm-2 (block)
KERNEL[2188.974779] change /devices/virtual/block/dm-2 (block)
dm-2
显然是出于某种原因。 dm-2
是我的主分区:
~$ ls -l /dev/mapper/
total 0
crw------- 1 root root 10, 236 Feb 20 11:25 control
lrwxrwxrwx 1 root root 7 Feb 20 12:02 home -> ../dm-2
lrwxrwxrwx 1 root root 7 Feb 20 11:25 sda3_crypt -> ../dm-0
lrwxrwxrwx 1 root root 7 Feb 20 11:25 swap -> ../dm-1
我对 dbus 和 udev 的理解至少可以说是有限的,但是一些谷歌搜索让我看到了这篇文章,该文章建议我创建一个文件/etc/udev/rulesd/90-fixdm.rules
,其中包含
ACTION=="add|change", KERNEL=="dm-*", OPTIONS:="nowatch"
这确实立即使这两个进程平静下来并恢复了我的 CPU 周期(并阻止笔记本电脑风扇持续运行)。然而,第二天笔记本电脑无法启动,挂在一个永远不会启动的“等待/dev/mapper/swap”作业上。一个惊慌失措的使用 Live-Ubuntu 棒从稍后删除文件/etc/udev/rulesd/90-fixdm.rules
,我回到原点 - 笔记本电脑再次启动,但高 CPU 使用率已经dbus-daemon
恢复system-udevd
。
可能发生了什么变化导致了这种新行为,我该怎么做才能解决这个问题?
谢谢。
看来我已经设法解决了这个问题。
一位朋友向我指出了这个关于 EXT4 的 MMP 特性的问题。检查有问题的设备
tune2fs -l /dev/dm-2 | grep -i mmp
表明这个(没有其他)文件系统确实启用了 MMP:我认为我不需要 MMP 功能,所以我尝试注销并以 root 身份登录控制台,以便我可以卸载,
/home
但即使卸载了它,我也无法删除 mmp 标志因为它总是说该设备正在使用中(据我所知,它没有)。我不得不在恢复模式下重新启动并进入 root shell,只有这样我才能删除 MMP 标志:然后我重新启动并正常登录,我现在运行时没有 dbus-daemon 和 systemd-udevd 的高 CPU 使用率,并且运行
udevadm monitor
不再产生无穷无尽的消息流。我只想提一下,因为对上述相关问题的回答提到这是较新版本的问题
udisks2
,但表明已修复我的 20.04.05LTS 安装似乎有版本2.8.4-1ubuntu2
,同样,该回答下的评论2.9.2-2+deb11u1
也表明仍然有同样的问题。