Изменяет ли файл override.conf фактическую конфигурацию файла службы?

Изменяет ли файл override.conf фактическую конфигурацию файла службы?

Я создал override.confфайл systemd-journal-catalog-update.serviceи поместил его в systemd-journal-catalog-update.service.d/каталог. Цель его удалить systemd-tmpfiles-setup.serviceизsystemd-journal-catalog-update.service file.

Теперь в файле есть следующее:

[Unit]
After=local-fs.target systemd-tmpfiles-setup.service

В моем override.confфайле есть следующее:

[Unit]
After=
After=local-fs.target

Однако systemd-journal-catalog-update.serviceфайл, похоже, не меняется. Я неправильно понимаю, как override.confработает файл? Я знаю, что могу вручную изменить исходный файл службы, но обстоятельства проекта ограничивают эту возможность. Любая помощь/совет, которые вы можете дать, будет высоко оценена.

решение1

То, что вы хотите (удаление зависимости из блока через файл drop-in), невозможно, согласноsystemd.единицаСтраница руководства:

Зависимости (After= и т. д.) нельзя сбросить до пустого списка, поэтому зависимости можно добавлять только в drop-in. Если вы хотите удалить зависимости, вам придется переопределить весь блок.

Переопределение всего файла модуля можно выполнить, следуя примеру 2 на странице руководства:

Существует два метода переопределения настроек поставщика в файлах модулей: копирование файла модуля из /usr/lib/systemd/system в /etc/systemd/system и изменение выбранных настроек. [...] Преимущество первого метода в том, что можно легко переопределить весь модуль, модуль поставщика больше не анализируется вообще. Недостаток метода в том, что улучшения файла модуля поставщиком не включаются автоматически при обновлениях.

В вашем случае вы должны (как root)

  • cp /usr/lib/systemd/system/systemd-journal-catalog-update.service /etc/systemd/system
  • systemctl daemon-reload
  • systemctl restart systemd-journal-catalog-update

После этого systemctl statusукажет на файл службы в /etc:

# systemctl status systemd-journal-catalog-update
● systemd-journal-catalog-update.service - Rebuild Journal Catalog
     Loaded: loaded (/etc/systemd/system/systemd-journal-catalog-update.service; static)
     Active: active (exited) since Sat 2021-05-22 16:27:07 CEST; 3 weeks 2 days ago
[...]

Вышеупомянутое systemctl catтакже не будет отображать файл в /etc/:

# systemctl cat systemd-journal-catalog-update
# /etc/systemd/system/systemd-journal-catalog-update.service
#  SPDX-License-Identifier: LGPL-2.1-or-later
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Rebuild Journal Catalog
[...]

Теперь вы можете отредактировать файл по /etcсвоему усмотрению, запустить его systemctl daemon-reloadснова и systemctl restart systemd-journal-catalog-updateзапустить службу с вашим пользовательским файлом модуля и его настройками.

Обратите внимание на следующее, упомянутое на странице руководства:

Недостатком является то, что улучшения файла устройства, внесенные поставщиком, не включаются автоматически в обновления.

Поскольку systemd теперь считывает совершенно другой файл модуля, нежели тот, что находится в пакете systemd вашего дистрибутива, вам необходимо вручную применить все обновления из файла /usr/libк своей собственной копии. .rpmnew(из дистрибутивов на основе RPM) или .pacnew(из дистрибутивов на основе pacman) файлы, которые обычно генерируются, если файл конфигурации, отслеживаемый менеджером пакетов, был изменен как локальным администратором, так и пакетом, который в этом случае не будет сгенерирован.

Связанный контент