发表文章

[C++] sysusers 人页状态错误字典命令 sysusers.d man page states wrong lexicographically order[systemd]

grazzolini 2017-10-9 27

提交类型

  • Bug 报告

systemd 版本该问题已被视为

234

使用的分发

Arch Linux

在错误报告的情况下: 预期的行为, 你没有看到

sysusers. d 人页状态: "如果多个文件指定相同的选项, 则具有字典最新名称的文件中的条目将优先处理。

在错误报告的情况下: 你看到的意外行为

这些文件的处理顺序与 "人" 页的状态相反, 第一个文件中的条目是所使用的, 最后一个被丢弃。

如果出现 bug 报告: 重现问题的步骤

  1. 创建两个文件, 其中有冲突的条目在任何目录 systemd 期望 sysusers 文件,/等,/运行或/或/或 lib。
  2. 运行 systemd-sysusers
  3. 第一个文件中的第一个条目将被使用, 第二个条目将被丢弃。

在调查 bug 报告时, 我遇到了这个问题: https://bugs.archlinux.org/task/54943

在安装 qemu 时, Arch Linux 已经添加了 kvm 组, 但有一个固定的组 id (GID) 为78。在部署了 systemd 234 后, 没有安装 qemu 的用户就得到了一个使用随机 GID 创建的 kvm 组。由于在 Arch Linux 上的所有 qemu/libvirt 配置都需要固定的 GID, 所以他们的 libvirt/qemu 安装是不起作用的。在234之前安装 qemu 的用户不受此影响。

在了解了这个问题之后, 我创建了一个具有固定 GID 并覆盖 systemd 配置的基本 arch 文件。但是, 词法, 这个文件是在 systemd 之前提供的基本。无论是人的页面需要改变或 systemd sysuser 本身。从我在其他 systemd 工具上看到的, 通常是第一个文件获胜, 我只看到另一种情况, 即最后一个是赢家。

原文:

Submission type

  • Bug report

systemd version the issue has been seen with

234

Used distribution

Arch Linux

In case of bug report: Expected behaviour you didn't see

The sysusers.d man page states: "If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence."

In case of bug report: Unexpected behaviour you saw

The files are processed in the reverse order of what the man page states, the entry in the first file being the one used and the last one being discarded.

In case of bug report: Steps to reproduce the problem

  1. Create two files with conflicting entries in any of the directories systemd expect sysusers files, /etc, /run or /usr/lib.
  2. Run systemd-sysusers
  3. The first entry in the first file will be used and the second entry will be discarded.

I have come across this issue when investigating a bug report: https://bugs.archlinux.org/task/54943

Arch Linux has been adding the kvm group when qemu is installed but with a fixed group id (GID) of 78. After systemd 234 was deployed, users which did not had qemu installed, got a kvm group created with a random GID. Since all of qemu/libvirt configuration on Arch Linux expects the fixed GID, their libvirt/qemu installation was non functional. Users who installed qemu before 234, are not affected by this.

After understanding the issue, I have created a basic-arch.conf file which has the fixed GID and overrides systemd configuration. But, lexically, this file is before systemd's provided basic.conf, not after. Either the man page needs to get changed or systemd-sysuser itself. From what I've seen on other systemd tools, usually the first file wins, I only saw one other case where it is stated that the last one wins.

相关推荐
最新评论 (14)
yuwata 2017-10-9
1

我已经测试了以下三文件/etc/sysusers.d

# 00-foo.conf
g foo     900     -            -
# 01-foo-aaa.conf
g foo     902     -            -
# 01-foo.conf
g foo     -     -            -

如果所有三文件都存在, 则将使用 gid 900 创建组 foo。没有 00-foo, 即, 只有 01-foo aaa 级和 01 foo. 组, 然后创建与 gid 902。所以, 这似乎没有问题。或者, 我可能会混淆你的问题。

原文:

I've tested with the following three files in /etc/sysusers.d

# 00-foo.conf
g foo     900     -            -
# 01-foo-aaa.conf
g foo     902     -            -
# 01-foo.conf
g foo     -     -            -

If all three files are exist, then the group foo is created with gid 900. Without 00-foo.conf, that is, only 01-foo-aaa.conf and 01-foo.conf exist, then the group is created with gid 902. So, it seems no problem. Or, I may confuse your problem.

yuwata 2017-10-9
2

如果相应的用户或组已经存在, Sysusers 将忽略该项。在创建组 kvm 之前, 您是否创建了基本的 arch。

原文:

Sysusers ignores an entry if the corresponding user or group already exists. Do you create basic-arch.conf before the group kvm is created?

grazzolini 2017-10-9
3

@yuwata
问题是行为与人页不匹配, 仅此而已。该人页指出将使用最后一个文件名, 而不是第一个。实际上我更喜欢它现在的工作方式, 匹配第一个文件名。只是那个人页面需要修理。我没有提供补丁, 因为我不知道, 如果人的页面将被修复, 或者如果 systemd sysusers 将得到修补, 以切换的行为。如果这只是一个男人页面的问题, 我很乐意提供一个补丁。

原文:

@yuwata
The issue is that the behavior does not match the man page, that's all. The man page states that the last filename will be used, not the first. I actually prefer how it works right now, matching the first filename. Just that the man page needs fixing. I have not provided a patch, because I don't know if the man page will be fixed, or if systemd-sysusers will get patched to switch the behavior. If it's just a man page issue, I'd be glad to provide a patch.

yuwata 2017-10-9
4

谢谢.我认为该人的页面应该是固定的。此行为与. 网络文件中的 tmpfiles 和类似的 [匹配] 部分相同。

原文:

Thanks. I think the man page should be fixed. This behavior is the same as the tmpfiles and similar to [Match] section in the .network file.

grazzolini 2017-10-9
5

@yuwata
我去寻找为这写公关, 但它似乎是从标准的 conf. xml 派生。该文件是由相当多的其他文件包括在内。我不知道是否所有这些工具都遵循相同的优先级, 但是如果 systemd 的正常优先级是第一个到最后的, 那么我猜想更改该文件将修复包括它在内的所有的人页面。

原文:

@yuwata
I went looking into writing a PR for this but it seems that this is derived from standard-conf.xml. And that file is include by quite a few other files. I don't know if all those tools follows the same precedence, but if the normal precedence on systemd is first to last, then I guess that changing that file will fix the man pages of all of those that includes it.

yuwata 2017-10-9
6

因此, sysusers 的 xml 不应包含标准的 conf. xml。我认为 tmpfiles. xml 中的 "配置格式" 一节的第二和第三段可以很好地参考。
请不要编辑标准的 conf. xml。

原文:

So, sysusers.d.xml should not to include standard-conf.xml. I think the second and third paragraph of the section "Configuration Format" in tmpfiles.d.xml can be a good reference.
Please do not edit standard-conf.xml.

grazzolini 2017-10-9
7

@yuwata
当然, 我不会更改文档, 而不确定所有包含它的手册页都以这种方式工作。我将尝试为今天准备一个补丁, 并发送一个公关。

原文:

@yuwata
Sure, I would not change the documentation without knowing for sure that all the man pages that includes it, actually work in that way. I'll try to prepare a patch for this today and send a PR.

stephankn 2017-10-9
8

我观察了 systemd-timesyncd 的类似问题。当我面对它与 Ubuntu 16.04 它有 systemd 229 我不能对这个旧的软件文件的 bug。

这很可能是文档错误也适用于此。

如果我将多个配置放在 timesyncd. conf. d 文件夹中使用第一个文件名的那个, 而不是在线中提到的最后一个。

将是伟大的, 如果你能做一个快速检查和调整的文件, 以及。解析配置的代码似乎在所有实用程序之间共享, 因此它们都受同一问题的影响。

原文:

I observed a similar issue with systemd-timesyncd. As I faced it with Ubuntu 16.04 LTS having systemd 229 I can't file a bug against this older software.

It sounds quite likely that the documentation bug also applies there.

If I place multiple configs in the timesyncd.conf.d folder the one with the first filename is used, as opposed to the last one mentioned in the manpage.

Would be great if you could do a quick check and adjust the documentation there as well. The code to parse config seems to be shared among all utilities, so they are all affected by the same issue.

yuwata 2017-10-9
9

@stephankn我不重现你的问题。我已经测试了多个配置, 但所有的设置似乎正确读取。
我注意到, systemd-timesyncd (8) 的人页指出,

systemd timesyncd 服务专门实现了 SNTP。

因此, timesyncd 在列出的服务器中只使用一个, 通常是第一个 NTP 服务器。
如果要使用第二个或更高版本中列出的 NTP 服务器, 我建议使用 NTP= 清除当前列出的服务器。例如,

# /etc/systemd/timesyncd.conf.d/a.conf
[Time]
NTP=ntp1.xxxx.org
# /etc/systemd/timesyncd.conf.d/b.conf
NTP=
NTP=ntp2.xxxx.org

然后, 您可以使用 ntp2.xxxx.org 作为 NTP 服务器。

原文:

@stephankn I do not reproduce your problem. I've tested with multiple drop-in configs but all settings seems correctly read.
I note that the man page systemd-timesyncd(8) states that

The systemd-timesyncd service specifically implements only SNTP.

So, timesyncd uses only one, usually the first, NTP server in listed servers.
If you want to use the NTP server listed in the second or later position, I propose to use NTP= to clear currently listed servers. E.g.,

# /etc/systemd/timesyncd.conf.d/a.conf
[Time]
NTP=ntp1.xxxx.org
# /etc/systemd/timesyncd.conf.d/b.conf
NTP=
NTP=ntp2.xxxx.org

Then you can use ntp2.xxxx.org as an NTP server.

stephankn 2017-10-9
10

@yuwata我很感激你试着帮助我。我不知道如何最好地进行, 因为这个问题可能会不同于原来在这里跟踪。我的印象是, 解析配置文件的代码仅存在于 systemd 的基代码中。因此, 它是否读取 timesyncd 配置或 sysusers 配置无关紧要。
并与它被证实, 文档是错误的, 词法第一个文件赢得这是符合我对 timesyncd 的意见。所以我在这里添加了评论。

我不知道如何最好地重现它与最近版本的 systemd, 能够创建一个专门的 bug 报告。与 Ubuntu 16.04 和 229, 它可以被视为:

# grep NTP= /etc/systemd/timesyncd.conf.d/*
/etc/systemd/timesyncd.conf.d/hetzner.conf:NTP=ntp1.hetzner.de ntp2.hetzner.com ntp3.hetzner.net
/etc/systemd/timesyncd.conf.d/zz-default.conf:NTP=0.de.pool.ntp.org time.google.com ntp.ubuntu.com

# systemctl restart systemd-timesyncd

# journal lists the server from the *first* file used.
Oct 06 00:22:05 kontiki systemd-timesyncd[30096]: Synchronized to time server [2a01:4f8:0:a0a1::2:1]:123 (ntp1.hetzner.de).

# mv zz-default.conf 00default.conf
# grep NTP= /etc/systemd/timesyncd.conf.d/*
/etc/systemd/timesyncd.conf.d/00default.conf:NTP=0.de.pool.ntp.org time.google.com ntp.ubuntu.com
/etc/systemd/timesyncd.conf.d/hetzner.conf:NTP=ntp1.hetzner.de ntp2.hetzner.com ntp3.hetzner.net

# systemctl restart systemd-timesyncd
# journal lists the server from the *first* file used.
Oct 06 00:28:00 kontiki systemd-timesyncd[30617]: Synchronized to time server 82.100.248.10:123 (0.de.pool.ntp.org).

因此与版本229清楚地第一个文件赢取, 并且词条在指南是错误的。
timesyncd 国家:

If multiple files specify the same option, the entry in the file with the lexicographically latest name takes precedence.

这显然是不正确的, 至少在229上,第一个文件获胜, 这也符合上面所做的文档更改。

那么如何进行呢?你是用同样的方式重现它吗?我是否应该打开一个专门的问题, 尽管版本是旧的?

原文:

@yuwata I am thankful you try to help me. I wonder how to best proceed as the issue might be different to what is originally tracked here. My impression was that the code to parse config files existed only once in the systemd codebase. So it would not matter whether it reads timesyncd config or sysusers config.
And with it being confirmed that documentation was wrong and the lexically first file wins this was in line with my observations regarding timesyncd. So I added the comment here.

I wonder how to best reproduce it with a recent version of systemd to be able to create a dedicated bug-report. With Ubuntu 16.04 LTS and 229 it can be seen as:

# grep NTP= /etc/systemd/timesyncd.conf.d/*
/etc/systemd/timesyncd.conf.d/hetzner.conf:NTP=ntp1.hetzner.de ntp2.hetzner.com ntp3.hetzner.net
/etc/systemd/timesyncd.conf.d/zz-default.conf:NTP=0.de.pool.ntp.org time.google.com ntp.ubuntu.com

# systemctl restart systemd-timesyncd

# journal lists the server from the *first* file used.
Oct 06 00:22:05 kontiki systemd-timesyncd[30096]: Synchronized to time server [2a01:4f8:0:a0a1::2:1]:123 (ntp1.hetzner.de).

# mv zz-default.conf 00default.conf
# grep NTP= /etc/systemd/timesyncd.conf.d/*
/etc/systemd/timesyncd.conf.d/00default.conf:NTP=0.de.pool.ntp.org time.google.com ntp.ubuntu.com
/etc/systemd/timesyncd.conf.d/hetzner.conf:NTP=ntp1.hetzner.de ntp2.hetzner.com ntp3.hetzner.net

# systemctl restart systemd-timesyncd
# journal lists the server from the *first* file used.
Oct 06 00:28:00 kontiki systemd-timesyncd[30617]: Synchronized to time server 82.100.248.10:123 (0.de.pool.ntp.org).

So with version 229 clearly the first file wins and the entry in the manual is wrong.
man timesyncd.conf states:

If multiple files specify the same option, the entry in the file with the lexicographically latest name takes precedence.

This is clearly not true as at least on 229 the first file wins, which is also in line with the documentation change done above.

So how to proceed? Are you reproducing it in the same way? Shall I open a dedicated issue, despite the version being older?

keszybz 2017-10-9
11

好吧, 文档似乎仍然不清楚。我会推另一个公关来澄清这一点。

原文:

OK, it seems that the documentation is still unclear. I'll push another PR to clarify this.

stephankn 2017-10-9
12

@keszybz啊, 它追加选项, 而不是覆盖它们。非常感谢您澄清了列表选项的重要细节。

是否有一个简单的方法来计算 NTP 设置的实际内容, 是吗?开机显示不列出它。如果看到完整的列表, 而不只是第一个条目被使用, 可能会更清楚地知道实际发生了什么。

因此, 如果可以很容易地列出列表选项的实际内容, 在 man-page 中提及如何阅读它肯定有助于其他人调试配置问题。

原文:

@keszybz Ah, it appends options, instead of overwriting them. Many thanks for clarifying this important detail for list options.

Is there an easy way to figure out what is the actual content of the NTP setting, is it? systemctl show does not list it. Would have made it probably much clearer what actually happend when seeing the full list and not just the first entry being used.

So if it is easily possible to list the actual content of list options, mentioning in the man-page how to read it certainly helps others to debug configuration issues.

keszybz 2017-10-9
13

如果第一台服务器没有响应, 它将切换到列表中的下一个条目。但不, 我不认为有办法显示这些信息。对于某些守护程序 (systemd, systemd 解决), 我们有方法可以将内部状态转储, 但不能将其全部丢弃。

原文:

It will switch to the next entry in the list if the first server does not respond. But no, I don't think there's a way to show this information. For some daemons (systemd, systemd-resolved) we have ways to dump internal state, but not for all of them.

yuwata 2017-10-9
14

@stephankn

是否有一个简单的方法来计算 NTP 设置的实际内容, 是吗?

这可能不是一个好主意, 但您可以通过创建下面的 "配置" 来确认设置。

# /etc/systemd/system/systemd-timesyncd.service.d/debug.conf
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
原文:

@stephankn

Is there an easy way to figure out what is the actual content of the NTP setting, is it?

It may not be a good idea, but you can confirm the setting by creating the following drop-in config.

# /etc/systemd/system/systemd-timesyncd.service.d/debug.conf
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
返回
发表文章
grazzolini
文章数
1
评论数
3
注册排名
60709