☰

无法激活服务“org.freedesktop.systemd1”：超时

tag-icon • tag-icon 16.04 systemd init
无法激活服务“org.freedesktop.systemd1”：超时

在 ubuntu 16.04.6 上尝试屏蔽 systemd 服务。我看到如下错误。

systemctl mask hadoop-hdfs-zkfc.service
Failed to activate service 'org.freedesktop.systemd1': timed out

我正在使用 Ubuntu 16.04.6 自带的默认 systemd 版本。

ubuntu@platform1:~$ systemctl --version
systemd 229
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD -IDN

这个问题并不总是会发生。但是一旦出现此问题，恢复 systemd 的唯一方法就是进行硬重启。

查看系统日志发现 systemd 已中止。

May 18 08:49:24 platform3 systemd[1]: Removed slice User Slice of support.
May 18 08:49:27 platform3 systemd[1]: Assertion 's->type ==
SERVICE_ONESHOT' failed at ../src/core/service.c:1792, function
service_enter_start(). Aborting.
May 18 08:49:27 platform3 systemd[1]: Caught <ABRT>, dumped core as pid 15839.
May 18 08:49:27 platform3 systemd[1]: Freezing execution.

busctl输出如下所示

ubuntu@platform3:~/logs$ busctl
NAME                               PID PROCESS         USER             CONNECTION    UNIT                      SESSION    DESCRIPTION
:1.1                               976 systemd-logind  root             :1.1          systemd-logind.service    -          -
:1.3                               971 accounts-daemon root             :1.3          accounts-daemon.service   -          -
:1.5434                          49174 systemctl       root             :1.5434       cron.service              -          -
:1.5435                          49223 systemctl       root             :1.5435       ssh.service               -          -
:1.5436                          49408 busctl          ubuntu           :1.5436       ssh.service               -          -
:1.7                              1109 unattended-upgr root             :1.7          unattended-upgrades.se... -          -
com.ubuntu.LanguageSelector          - -               -                (activatable) -                         -
org.debian.AptXapianIndex            - -               -                (activatable) -                         -
org.freedesktop.Accounts           971 accounts-daemon root             :1.3          accounts-daemon.service   -          -
org.freedesktop.DBus               936 dbus-daemon     messagebus       org.freedesktop.DBus dbus.service              -          -
org.freedesktop.hostname1            - -               -                (activatable) -                         -
org.freedesktop.locale1              - -               -                (activatable) -                         -
org.freedesktop.login1             976 systemd-logind  root             :1.1          systemd-logind.service    -          -
org.freedesktop.network1             - -               -                (activatable) -                         -
org.freedesktop.resolve1             - -               -                (activatable) -                         -
org.freedesktop.systemd1             - -               -                (activatable) -                         -
org.freedesktop.thermald             - -               -                (activatable) -                         -
org.freedesktop.timedate1            - -               -                (activatable) -                         -

有人能告诉我如何调试这个吗？

该问题与讨论的问题类似这里。那么这是 Ubuntu 16.04.6 上一些已知的 systemd 问题吗？

答案1

从您上面发布的 busctl 调用的输出可以清楚地看出，您的org.freedesktop.systemd1守护进程（init.scope单元）实际上并未处于活动状态：

org.freedesktop.systemd1             - -               -                (activatable) -                         -

然而它可能被像这样激活：

$ systemctl daemon-reexec

或这个：

$ sudo kill 1

这应该以更坚持的方式要求 systemd - 通过向 systemd 发送 SIGTERM 信号，执行基本相同的操作 - 运行 daemon-reexec。在耗尽所有可用 RAM 且系统上没有交换文件后，我遇到了类似的问题。重新执行 systemd 守护进程完全解决了这个问题，而无需重新启动机器（尽管在此之前，如果问题的起因与我的情况相同，则需要终止一些用户进程以释放一些 RAM）。正如 systemd 的手册页中所述，daemon-reexec 易于使用：

   daemon-reexec
       Reexecute the systemd manager. This will serialize the manager
       state, reexecute the process and deserialize the state again. This
       command is of little use except for debugging and package upgrades.
       Sometimes, it might be helpful as a heavy-weight daemon-reload.
       While the daemon is being reexecuted, all sockets systemd listening
       on behalf of user configuration will stay accessible.

答案2

systemd 邮件列表中已回答了这个问题。交叉发布答案

这个错误（https://github.com/systemd/systemd/issues/4444) 已在 systemd v236 中修复。

看看是否可以使用较新版本的 systemd。

相关内容