在DevStack中使用Systemd

默认情况下，DevStack以Systemd单元文件的形式运行所有服务。Systemd现在是几乎每个Linux发行版的默认init系统，并且对许多与运行不良的进程相关的问题进行编码和解决。

为什么这个而不是屏幕？¶

DevStack的屏幕模型是在DevStack用户将要运行的服务数量通常小于10时发明的，这使得屏幕热键很容易跳过。然而，情况已经发生了变化(并不是所有的服务在屏幕上都是可停止的，因为有些服务在apache下，通常至少有20个项)

还有一个通用的开发人员工作流，用于更改多个服务中的代码，并且需要重新启动一组服务才能生效。

单位结构¶

注

最初，我们实际上想作为用户单元来执行这个任务，但是在非交互式shell下运行这个程序存在问题。现在，我们将作为系统单元运行。一些用户单元代码被保留在适当的位置，以防我们稍后可以切换回来。

所有DevStack用户单元都是在给定名称的DevStack片中创建的devstack@$servicename.service…这使得我们很容易理解哪些服务是dev堆栈运行的一部分，并允许我们在一个命令中禁用/停止它们。

操纵单位¶

假设单位n-cpu让这些例子更清楚。

启用一个单元(允许启动它)：

sudo systemctl enable [email protected]

禁用一个单元：

sudo systemctl disable [email protected]

启动一个单元：

sudo systemctl start [email protected]

停止某单位：

sudo systemctl stop [email protected]

重新启动一个单元：

sudo systemctl restart [email protected]

见单位状况：

sudo systemctl status [email protected]

一次在多个单元上操作¶

Systemd支持单元操作的通配符。要重新启动dev堆栈中的每个服务，可以执行以下操作：

sudo systemctl restart devstack@*

或者要查看所有Nova流程的状态，您可以这样做：

sudo systemctl status devstack@n-*

我们最终将使单元名称更有意义，以便更容易理解您正在重新启动的内容。

查询日志¶

与systemd一起提供的其他主要功能之一是日志，这是一种访问日志的统一方法(包括通过结构化元数据进行查询)。这是用户通过journalctl命令。

日志可以通过journalctl…Journal alctl具有强大的查询功能。我们将从一些共同的选择开始。

跟踪特定服务的日志：

sudo journalctl -f --unit [email protected]

同时记录多个服务的日志如下：

sudo journalctl -f --unit [email protected] --unit [email protected]

或者，您甚至可以使用通配符来跟踪所有的nova服务：

sudo journalctl -f --unit devstack@n-*

使用更高精度的时间戳：

sudo journalctl -f -o short-precise --unit [email protected]

默认情况下，日志删除“不可打印”字符，包括ASCII颜色代码。保留颜色代码(可由适当的终端/寻呼机解释)。less，默认)：

sudo journalctl -a --unit [email protected]

当使用默认寻呼机输出到终端时，长行将被截断，但通过左/右箭头键支持水平滚动。可以通过设置SYSTEMD_LESS环境变量改为环境变量。FRXM.

您可以将输出输送到另一个工具，如grep…例如，要在nova日志中找到服务器实例UUID：

sudo journalctl -a --unit devstack@n-* | grep 58391b5c-036f-44d5-bd68-21d3c26349e6

看见man 1 journalctl为了更多。

调试¶

使用PDB¶

为了在系统控制的服务上进入常规的PDB会话，您需要手动调用流程–也就是说，将它从systemd的控制中删除。

发现用于运行服务的命令系统：

systemctl show [email protected] -p ExecStart --no-pager

停止system d服务：

sudo systemctl stop [email protected]

将断点注入源，例如：

import pdb; pdb.set_trace()

手动调用命令：

/usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf

一些可执行文件，如新计算，将需要与特定组一起执行。这将显示在systemd单元文件中：

sudo systemctl cat [email protected] | grep Group
Group = libvirt

使用SG作为这个组执行命令的工具：

sg libvirt -c '/usr/local/bin/nova-compute --config-file /etc/nova/nova-cpu.conf'

使用远程PDB¶
远程PDB在系统控制进程时工作。

确保安装了Remote-PDB：

sudo pip install remote-pdb

将断点注入源，例如：

import remote_pdb; remote_pdb.set_trace()

重新启动相关服务：

sudo systemctl restart [email protected]

时，远程-pdb代码配置telnet端口。set_trace()被调用。尽一切努力访问已检测的代码路径，并检查日志以查看显示侦听端口的消息：

Sep 07 16:36:12 p8-100-neo [email protected][772]: RemotePdb session open at 127.0.0.1:46771, waiting for connection ...

远程登录到该端口以进入PDB会话：

telnet 127.0.0.1 46771

见远程PDB有关更多选项的主页。

已知问题¶
小心系统python库。在Pypi上有三个，它们都是非常不同的。不幸的是，它们都安装在systemd命名空间，这可能会导致一些问题。

systemd-python-这是上游维护的库，它有一个类似于systemd本身的版本号(目前234)。这是你想要的。

systemd-蟒蛇3只有图书馆，而不是你想要的。

python-systemd-又一个你不想要的图书馆在系统上安装它将破坏Ansible的运行能力。

如果我们使用的是用户单元，则[Service] - Group=参数似乎不适用于用户单元，尽管文档中说应该这样做。这意味着我们需要做一个明确的/usr/bin/sg…这样做的缺点是使syslog_标识符成为sg…我们可以使用SyslogIdentifier=，但很不幸，我们需要这项工作。这目前没有问题，因为我们只使用系统单元。

参考链接 ：
https://docs.openstack.org/devstack/latest/systemd.html