O arquivo override.conf altera o arquivo de serviço real conf?

O arquivo override.conf altera o arquivo de serviço real conf?

Eu criei um override.confarquivo systemd-journal-catalog-update.servicee coloquei-o no systemd-journal-catalog-update.service.d/diretório. O objetivo é remover systemd-tmpfiles-setup.servicedosystemd-journal-catalog-update.service file.

O arquivo tem isso agora:

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

Meu override.confarquivo tem isso:

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

No entanto, o systemd-journal-catalog-update.servicearquivo não parece estar mudando. Estou entendendo mal como o override.confarquivo funciona? Eu sei que posso modificar manualmente o arquivo de serviço original, mas as circunstâncias do projeto estão limitando essa opção. Qualquer assistência/conselho que vocês possam dar será muito apreciada.

Responder1

O que você deseja (remover uma dependência da unidade através de um arquivo drop-in) não é possível, de acordo com ounidade do sistemapágina de manual:

As dependências (After=, etc.) não podem ser redefinidas para uma lista vazia, portanto, as dependências só podem ser adicionadas em drop-ins. Se quiser remover dependências, você deverá substituir a unidade inteira.

A substituição de um arquivo de unidade inteiro pode ser feita seguindo o Exemplo dois na página man:

Existem dois métodos para substituir as configurações do fornecedor em arquivos de unidade: copiar o arquivo de unidade de /usr/lib/systemd/system para /etc/systemd/system e modificar as configurações escolhidas. [...] A vantagem do primeiro método é que se substitui facilmente a unidade completa, a unidade do fornecedor não é mais analisada. Tem a desvantagem de que as melhorias feitas no arquivo da unidade pelo fornecedor não são incorporadas automaticamente nas atualizações.

No seu caso, você deve (como root)

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

Depois disso, systemctl statusapontará para o arquivo de serviço em /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
[...]

O mencionado acima systemctl cattambém não mostrará o arquivo em /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
[...]

Agora você pode editar o arquivo /etccomo desejar, executá-lo systemctl daemon-reloadnovamente e systemctl restart systemd-journal-catalog-updateexecutar o serviço com seu arquivo de unidade personalizado e suas configurações.

Observe o seguinte mencionado na página de manual:

Tem a desvantagem de que as melhorias feitas no arquivo da unidade pelo fornecedor não são incorporadas automaticamente nas atualizações.

Como o systemd agora lê um arquivo de unidade completamente diferente daquele que está no pacote systemd da sua distribuição, você deve aplicar manualmente quaisquer atualizações do arquivo em /usr/libsua própria cópia. .rpmnew(de distribuições baseadas em RPM) ou .pacnew(de distribuições baseadas em pacman) que normalmente são gerados se um arquivo de configuração rastreado pelo gerenciador de pacotes tiver sido modificado pelo administrador local e o pacote não será gerado neste caso.

informação relacionada