主页 / ubuntu / 问题 / 1241017
Accepted
tuk
Asked: 2020-05-19 07:06:55 +0800 CST

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

  • 772

在 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 问题吗？

init systemd 16.04

2 个回答

  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.
    • 3
  2. Best Answer

    这已在 systemd 邮件列表中得到解答。交叉发布答案

    此错误（https://github.com/systemd/systemd/issues/4444）已在 systemd v236 中修复。

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

    • 1

相关问题