小编Til*_*idt的帖子

我正在尝试将 nginx 与 uwsi 一起使用。

我写了 uwsgi ini 文件并用 uwsgi --ini site.ini 测试它

一切正常。

但是，当我尝试运行该站点时，出现以下错误（来自日志文件）：

*** Python threads support is disabled. You can enable it with --enable-threads$
Python main interpreter initialized at 0x1a297d0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 800360 bytes (781 KB) for 10 cores
*** Operational MODE: preforking ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1a297d0 pid: 177$
*** …

在我们的一台服务器上，yum history报告：

[tschmidt@sl-was01p ~]$ sudo yum history
Loaded plugins: product-id, search-disabled-repos, security, subscription-
              : manager
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    30 | <dlewandowski>           | 2016-10-07 11:18 | E, I, U        |   38 EE
    29 | <dlewandowski>           | 2016-09-16 16:13 | Erase          |    3   
[...]

但是报告的登录用户发誓他当时没有靠近机器（物理上或逻辑上），并且last似乎支持这一点：

[tschmidt@sl-was01p ~]$ last|grep dle
dlewando pts/0        al-dlewandowski. Tue Oct 11 09:01 - 09:23  (00:22)    
dlewando pts/0        al-dlewandowski. Tue Oct 11 08:37 - 08:40 …

我已经从存储库https://build.opensuse.org/package/show/home%3AXimi1970%3AopenSUSE%3AExtra/bacula在https://software.opensuse.org推荐的 openSUSE Leap 42.3 系统上安装了 Bacula 7.4.4 /包/bacula。这些包使用 openSUSE 的替代机制来配置用于目录的 DMBS - 在我的例子中是 MySQL。不幸的是，这个包有点问题。安装 bacula-director 和 bacula-mysql 软件包后，/usr/lib64 中 libbaccats 库的符号链接如下所示：

libbaccats.so -> /etc/alternatives/libbaccats.so
libbaccats-mysql.so -> libbaccats-mysql-7.4.4.so
libbaccats-stub.so -> libbaccats-7.4.4.so
libbaccats-7.4.4.so -> libbaccats-stub-7.4.4.so

最后两个显然是无稽之谈，并导致任何运行 director 或 dbcheck 实用程序的尝试都失败并显示错误消息：

致命错误：请用正确的库替换这个空的 libbaccats 库。

这当然可以通过发出以下命令轻松解决：

ln -sf libbaccats-stub-7.4.4.so libbaccats-stub.so
ln -sf /etc/alternatives/libbaccats-7.4.4.so libbaccats-7.4.4.so

产生所需的结果：

libbaccats.so -> /etc/alternatives/libbaccats.so
libbaccats-7.4.4.so -> /etc/alternatives/libbaccats-7.4.4.so
libbaccats-mysql.so -> libbaccats-mysql-7.4.4.so
libbaccats-stub.so -> libbaccats-stub-7.4.4.so

它允许 /etc/alternatives 中的符号链接：

libbaccats.so -> /usr/lib64/libbaccats-mysql.so
libbaccats-7.4.4.so -> /usr/lib64/libbaccats-mysql-7.4.4.so

正确地将 libbaccats 引用指向 …

三周内，我的两台 Ubuntu 20.04LTS 服务器systemd突然变得无响应。症状：

• 所有systemctl用于控制服务或访问日志的命令都会失败并显示错误消息：

Failed to retrieve unit state: Connection timed out
Failed to get properties: Connection timed out

• systemd不理会logrotate重新打开日志的信号，继续写入重命名的日志文件/var/log/syslog.1，而新创建的日志文件/var/log/syslog仍为空。
• 许多僵尸进程从 cronjobs 和系统管理任务中积累，即。PID 1 systemd 忽略了其收集孤立进程的职责。
• 正在运行的服务继续正常运行，但不再可能启动或停止服务，因为即使旧脚本也重定向/etc/init.d到非功能性systemctl.
• Connection timed out除了尝试与 交互的消息之外，日志中没有任何异常systemd。

普遍提出的纠正措施：

• systemctl daemon-reexec
• kill -TERM 1
• 去除/run/systemd/system/session-*.scope.d

不要解决问题。唯一的补救措施是重新启动整个系统，这对于地球另一端的服务器来说当然既具有破坏性又存在问题。

在大约 100 台服务器中，Ubuntu 16.04LTS 大约每月都会出现一次同样的问题。自从升级到 20.04LTS 以来，这种情况已经少了很多，但并没有完全消失。在自 20.04LTS 以来受到攻击的两台服务器中，其中一台在运行 16.04LTS 时就已经受到攻击。

问题：

• 造成此类systemd故障的可能原因是什么？
• 我该如何进一步诊断？
• 有没有比systemd重新启动破坏性更小的方法来从无响应中恢复？