主页 / unix / 问题 / 791979
Accepted
Seamus
Asked: 2025-03-05 13:04:00 +0800 CST

控制 systemd“切片”中包含哪些服务

  • 772

我重写了开头这段话……试图掩饰我对的蔑视systemd。我只能说我发现systemd的“逻辑”令人费解，就此打住。回到问题：

systemd-analyze time我一直在尝试减少小型Raspberry Pi Zero 2W上报告的启动时间。该操作系统约 95% 是 Debian，并加入了一些 Raspberry Pi 来处理硬件。

我首先列出活动的单元文件，然后从该列表中我找到了几个service我相信可以毫无影响地删除的文件：

$ systemctl list-unit-files --state=enabled
...
rpi-display-backlight.service      enabled enabled
rpi-eeprom-update.service          enabled enabled
...
$

我选择disable这两项服务如下：

$ sudo systemctl disable rpi-eeprom-update.service rpi-display-backlight.service
Removed "/etc/systemd/system/halt.target.wants/rpi-display-backlight.service".
Removed "/etc/systemd/system/poweroff.target.wants/rpi-display-backlight.service".
Removed "/etc/systemd/system/reboot.target.wants/rpi-display-backlight.service".
Removed "/etc/systemd/system/multi-user.target.wants/rpi-eeprom-update.service".

令人失望的是，我发现启动时间（据报告systemd-analyze time）实际上增加了约 3 秒。我重新启动了几次以获得“平均值”；3 秒的增加看起来是真实且持续的。我想知道这种增加是否可能是由于systemd 重新尝试启动这些服务造成的。因此我寻找与其他“单元”的依赖关系systemd：

$ systemctl list-dependencies rpi-eeprom-update.service
rpi-eeprom-update.service

$ systemctl list-dependencies rpi-display-backlight.service
rpi-display-backlight.service
● └─system.slice
$

我认为第一个结果 (rpi-eeprom) 表明没有其他依赖项。第二个结果 (rpi-display) 让我感到困惑。.slice从那时起，我做了一些研究，但它对我来说仍然没有什么意义（实际上没有意义）。这引出了我的问题：

有人能解释一下如何编辑这个system.slice并删除吗rpi-display-backlight.service？

debian

1 个回答

  1. Best Answer

    您似乎对切片的概念存在误解。请允许我先介绍一些背景知识。

    切片是 systemd 资源簿记层次结构的一个单位：对切片的依赖不会强制启动服务。相反：在建立资源簿记之前（即已安装和虚拟文件系统），不允许启动服务。一旦安装了真正的根文件系统，就会发生这种情况，因此限制并不大。/sys/sys/fs/cgroup

    任何管理流程的单元（主要是范围和服务单元）都可以分配给特定的切片：如果没有定义更具体的切片，则任何系统或单元的默认分类为。任何实例化服务单元（名称中带有 的单元）都会获得一个 子切片，该子切片可以跟踪该特定模板的所有实例的资源使用情况。*.service*.scopesystem.slice@system.slice

    例如：

    • 所有没有定义更具体切片的系统服务都包含在system.slice
    • 如果您使用getty来激活串行端口的进程，您将自动获得一个，它跟踪所有服务的总资源使用情况。这是 的子片段。systemctl enable [email protected]system-serial\x2dgetty.sliceserial-getty@...system.slice
    • 管理的所有用户登录systemd-logind均计入user.slice，每个登录用户都由子user-<UID>.slice切片单独跟踪。其中包括用户服务，即每个用户的后台服务：请参阅systemctl --user list-units --type=service。
    • 如果您在 的管理下运行虚拟机或容器systemd-machined，您将获得一个machine.slice跟踪所有虚拟机/容器的总资源使用情况的数据，以及一个machine-<VM/container ID>.slice跟踪每个特定虚拟机/容器的子切片。

    为了获得更直观的理解，请尝试运行systemd-cgtop并想象您的系统被某些东西占用，但不知道具体是什么。是某些用户做了不该做的事情，还是某个配置错误或受到外部攻击的服务进程？

    您可以选择激活资源限制跟踪，并对任何服务或分片设置资源使用限制。例如，如果您的系统运行着某个关键服务和一些非必要服务，那么您可以将非必要服务放入单独的分片（可能是的子分片system.slice），然后向该分片添加ConditionMemoryPressure=和ConditionCPUPressure=/或ConditionIOPressure=，以使系统在内存/CPU/IO 负载过高时自动关闭所有非必要进程（或者如果非必要进程包括*.timer运行定期非必要任务的单元，则首先不启动它们）。man systemd.resource-control有关详细信息，请参阅。

    如果您希望单独跟踪特定服务或服务组的资源使用情况，您可以Slice=something.slice在[Service]相应服务的部分添加一行。

    您的下一个问题可能是“那么，为什么rpi-display-backlight.service依赖于system.slice而rpi-eeprom-update.service不依赖于 呢？”说实话，我暂时还不确定。但我猜想这可能意味着rpi-eeprom-update是 的服务Type=oneshot，它不应该让任何长期存在的进程运行，并且rpi-display-backlight会启动至少一个服务进程，该进程的资源使用量被算作 的一部分，system.slice因为没有定义更具体的部分，并且system.slice是所有服务的默认部分。

    重申一下：如果某个单元依赖于某个切片单元，则systemd不会尝试重新启动该单元。这只意味着该单元启动的长期进程的任何资源使用量都将计入指定切片中。

    如果要更改的切片依赖性rpi-display-backlight.service，只需添加一个/etc/systemd/system/rpi-display-backlight.service.d/override.conf包含以下内容的文件：

    [Service]
Slice=system-separate.slice

    如果你想rpi-display-backlight.service在一个单独的子切片中，它仍然总计在下system.slice，或者

    [Service]
Slice=separate.slice

    如果您希望将其资源使用量排除在总数之外system.slice。

    与往常一样，更改服务配置文件后，运行systemctl daemon-reload。或者使用进行更改systemctl edit rpi-display-backlight.service，它会自动为您执行此操作（并且允许您轻松还原更改或在出现语法错误时重新编辑）。

    • 1

相关问题