未能激活服务'org.freedesktop.systemd1'：超时

Question

关于ubuntu16.04.6试图掩盖一个systemd服务。我看到下面这样的错误。

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

我使用的是Ubuntu16.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

这个问题并不总是会出现。但是一旦这个问题被击中，恢复系统的唯一方法就是做一个硬重新启动。

看看syslog，它的系统似乎被中止了。

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 , 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) -                         - 

有人能告诉我，怎么调试这个吗？

这个问题看起来类似于讨论这里的问题。这是Ubuntu16.04.6上已知的系统问题吗？

Answer 1

这已经在systemd邮件列表中得到了回答。交叉张贴答案

这个bug (https://github.com/systemd/systemd/issues/4444)是在systemd v236中修复的。看看是否可以使用较新版本的systemd。

Answer 2

从查看上面发布的busctl调用的输出可以清楚看出，您的org.freedesktop.systemd1守护进程(init.scope单元)实际上并不是活动的：

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

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

$ systemctl daemon-reexec

或者这个：

$ sudo kill 1

它应该要求systemd以一种更坚决的方式-通过向systemd发送一个SIGTERM信号来执行本质上相同的运行守护进程-reexec。在系统上没有交换文件的同时耗尽了所有空闲内存后，我发现了一个相似的问题。并且重新执行systemd守护进程完全解决了它，而不需要重新启动机器(尽管在此之前，如果问题是以与我的情况相同的方式造成的，您需要杀死一些用户进程来释放一些RAM )。正如该系统的手册页所述，守护进程-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.