标签: systemd

我找到了这些针对 syslogd 的解决方案，它们在某些事件（如 local0.crit 或 local1.err）上发送电子邮件

如何让 syslogd 通过电子邮件将某些日志消息发送给我？ http://www.johnandcailin.com/blog/john/how-setup-real-time-email-notification-critical-syslog-events

但是，我的系统在 systemd 上运行，因此将日志用于系统日志。如何在不运行 cron 每 5 分钟检查所有日志并将日志发送到地址或类似地址的情况下基于事件实施电子邮件？

为什么 timezonectl 没有列出所有可用的时区？

$ timedatectl
  ?
  Timezone: UTC (UTC, +0000)
  ?

$ timedatectl list-timezones | grep -i utc
  -no output-

$ timedatectl list-timezones | wc -l
  417

ls /usr/share/zoneinfo 包括 UTC、UCT、GMT、Universal 等。但这些也不包括在列表中。

我在 CentOS 7 中特别注意到了这一点，并且在两台不同的机器上得到了相同的结果。然而，有趣的是，Ubuntu 显示“UTC”而不是“GMT”。./zoneinfo 中确实存在。所以整件事让我很困惑。

以 systemd-cgls 中的层次结构为例：

\xe2\x94\x94\xe2\x94\x80user.slice\n  \xe2\x94\x9c\xe2\x94\x80user-1000.slice\n  \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x80user@1000.service\n  \xe2\x94\x82 \xe2\x94\x82 \xe2\x94\x94\xe2\x94\x80init.scope\n  \xe2\x94\x82 \xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x803262 /lib/systemd/systemd --user\n  \xe2\x94\x82 \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x803263 (sd-pam)  \n  \xe2\x94\x82 \xe2\x94\x94\xe2\x94\x80session-3.scope\n  \xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x803260 sshd: user1 [priv]\n  \xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x803362 sshd: user1@pts/1 \n  \xe2\x94\x82   \xe2\x94\x9c\xe2\x94\x803363 -bash\n  \xe2\x94\x82   \xe2\x94\x94\xe2\x94\x803378 ssh-agent -s\n  \xe2\x94\x94\xe2\x94\x80user-0.slice\n    \xe2\x94\x9c\xe2\x94\x80session-1.scope\n    \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x803151 sshd: root@pts/0    \n    \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x803252 -bash\n    \xe2\x94\x82 \xe2\x94\x9c\xe2\x94\x803625 systemd-cgls\n

如果我为 user.slice 设置限制，例如 5M 内存，Memory 行会清楚地报告它：

systemctl status user.slice\n\xe2\x97\x8f user.slice\n   Loaded: loaded (/etc/systemd/system/user.slice; static; vendor preset: enabled)\n   Active: active since Mon 2016-08-22 11:32:13 CEST; 52min …

当我编写单元文件时，我希望Exec*-options ( ExecStartPre=, ExecStartPost=, ExecStart=, and ExecStopPost=) 的所有输出都发送到日志。但显然输出以某种方式缓冲，因此无法确定将写入日志的内容。

在我的单元文件 ( ulftest.service) 中，我有以下部分：

...
ExecStartPre=/bin/echo 'Hello'
ExecStartPre=/usr/bin/who
ExecStart=/storage/_test/venv/bin/python /storage/_test/ulftestservice.py
...

因此，除了正常的“开始”、“已开始”、“停止”和“已停止”行之外，我希望日志中会显示一个已登录用户的列表（我有 4 个用户）和一个“ Hello” 。

不是这种情况。如果它们出现或不出现，这完全是随机的（至少对我来说）。

我编写了一个小测试循环，每 2 秒重新启动一次服务：

$ for x in `seq 100`; do echo $x; sudo systemctl restart ulftest.service ; sleep 2; done

运行之后我在日志中得到了这个：

...
2017-05-10T09:40:36+0000 ulf44 systemd[1]: Started UlfTest, Administrative interface.
2017-05-10T09:40:38+0000 ulf44 systemd[1]: Stopping UlfTest, Administrative interface...
2017-05-10T09:40:38+0000 ulf44 systemd[1]: Stopped UlfTest, Administrative interface.
2017-05-10T09:40:38+0000 ulf44 systemd[1]: Starting UlfTest, Administrative interface... …

我正在使用一些模板化计时器单元来运行一组模板化服务。有些备份作业和关联的维护任务需要备份存储库上的独占锁，并且不能与备份作业同时运行。我正在尝试弄清楚如何设置这些单元，以便正确排序作业。

例如，我有以下服务模板：

• backup@.service
• clean@.service

我有以下计时器模板：

• backup-daily@.timer
• backup-weekly@.timer
• clean-daily@.timer
• clean-weekly@.timer

单元backup-daily@.timer启动相应backup@.service实例的位置可能类似于：

[Unit]
Description=daily backup of %i

[Timer]
OnCalendar=daily
Unit=backup@%i.service

[Install]
WantedBy=timers.target

如果我跑...

systemctl enable --now backup-daily@foo.timer clean-daily@foo.timer

...我需要确保 clean@foo 服务在 backup@foo 服务完成之前不会运行。

到目前为止，我想出的唯一解决方案是放弃OnCalendar=daily并使用显式启动时间，以便我可以保证备份作业首先启动（例如，在凌晨 1 点启动备份作业，在凌晨 2 点启动维护作业），然后利用某种锁定（例如，flock）命令可确保维护作业在备份作业完成后才开始。

这可行，但有点hacky。如果有更好的方法使用 systemd 来解决这个问题，我想弄清楚。

我使用Nagios Core、NRPE和check_disk监控 Ubuntu 服务器上的可用磁盘空间。

在以前的 Ubuntu 版本中，我曾经得到类似这样的输出：

DISK OK - free space: / 43754 MB (80% inode=86%):

相反，在 Ubuntu 18.04.1 上，我得到：

DISK OK - free space: /var/tmp 43754 MB (80% inode=86%):

我看到/var/tmp根/分区的安装点不正确。我跟踪此行为依赖PrivateTmp=true于nagios-nrpe-server.service：

• 我去查看/var/tmp并发现了一个名为systemd-private-c5b5d3d362364af19af640147f2cb844-nagios-nrpe-server.service-4uILRy
• 然后检查服务定义并注意到（例如Ubuntu 16.04 上的NRPE2PrivateTmp=true不存在）
• 最后，尝试删除该行，然后根挂载点被检测为/

我觉得我面临三个选择：

1. 忍受它。

2. 消除PrivateTmp=true。

3. 找到合理的解决方法。

我倾向于接受它，但如果我更清楚没有私人/tmp服务的影响，我可以对选项 2 做出明智的选择。

最佳解决方案可能是找到一种解决方法，指示check_disk即使在这种情况下也返回正确的安装点信息。无法访问系统/tmp不应构成障碍。

问题：请说明 的含义PrivateTmp=true，解释为什么建议使用它，在什么情况下以及有哪些注意事项可以将其删除。

第二个问题：check_disk …

我有两个单元，nginx.service 和 certbot.service，由它们各自的 Debian 软件包提供：

nginx.服务：

[Unit]
Description=A high performance web server and a reverse proxy server
Documentation=man:nginx(8)
After=network.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid
TimeoutStopSec=5
KillMode=mixed

[Install]
WantedBy=multi-user.target

certbot.服务：

[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

还有一个计时器 certbot.timer （也由 certbot deb 包提供）：

[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00 …

I have an AWS EC2 instance running a CentOS 7.7.1908 (systemd 219) with a server application. The server logs quite a lot of information to the system logs (using syslog).

I have recently enabled persistent storage of the system logs using this answer. Since then, the memory consumption of systemd-journald is constantly growing.

After a full day, systemd-journald ends up using more than 250M of RAM.

我做了一个快速测试来确认 Journald RAM 使用量实际上在增长。

测试 ：

• 获取systemd-journald内存使用情况
• 使用以下命令将一堆数据记录到系统日志中logger
• 获取 …

要通过名称访问网络上的其他计算机，我必须将以下两行添加到我的/etc/resolv.conf：

search foo.local
nameserver 192.168.X.Y

但我所做的任何更改在重新启动后都不会保留。

这是 my 的内容/etc/resolv.conf，它实际上是以下符号链接/run/systemd/resolve/stub-resolv.conf：

$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must …

在 Debian 10 上，service rabbitmq-server start需要 10 秒；service rabbitmq-server stop需要 5 秒。

这适用于负载极低且启动/停止速度比 RabbitMQ 性能或可靠性更重要的 Docker 开发环境。因此，停止并重新启动容器需要 15 秒。

我怎样才能让它更快？我添加log.default.level = debug了rabbitmq.conf以防万一它会告诉我它在启动过程中正在做什么，但它没有给我任何有用的东西。