Modificar parâmetros dos arquivos de unidade do systemd

O gerenciador de pacotes coloca os arquivos de unidade na pasta /usr/lib/systemd/system. Não devem ser editados manualmente. Caso você queira modificar algo, a maneira correta é copiá-lo para /etc/systemd/system, editá-lo ali e rodar systemctl daemon-reload:

# cp /usr/lib/systemd/system/<nome>.<tipo> /etc/systemd/system
# nano /etc/systemd/system/<nome>.<tipo>
# systemctl daemon-reload

Arquivos com o mesmo nome em /etc têm prioridade frente aos de /usr.

Também é possível usar a diretiva .include para poupar texto quando apenas queremos mudar um parâmetro ou outro. Para adicionarmos, por exemplo, uma dependência a determinada unidade:

/etc/systemd/system/<nome>.<tipo>

.include /usr/lib/systemd/system/<nome>.<tipo>

[Unit]
After=blabla.service
Wants=blabla.service

A partir do systemd 198, são suportados arquivos drop-in de configuração no diretório /etc/systemd/system/<nome>.<tipo>.d (precisa ser criado de acordo com o nome da unidade). Qualquer arquivo com a extensão .conf será interpretado e aplicado sobre os valores configurados na unidade presente em /usr ou /etc.

# mkdir /etc/systemd/system/<nome>.<tipo>.d

Depois, dentro d o diretório, criar um (ou mais) arquivo .conf contendo a configuração desejada.

/etc/systemd/system/<nome>.<tipo>.d/teste.conf

[Unit]
After=blabla.service
Wants=blabla.service

Não sendo necessário usar .include. Depois, recarregamos a configuração com systemctl daemon-reload e, dependendo do tipo de unidade e modificação feita, reiniciá-la com systemctl restart <nome>.<tipo>. A partir da versão 201, systemctl status <nome>.<tipo> lista drop-ins existentes.

systemd-delta (disponível a partir da versão 183) é útil para exibir um panorama do que está sendo substituído:

# systemd-delta -t overridden
[OVERRIDDEN] /etc/systemd/system/upower.service -> /usr/lib/systemd/system/upower.service

--- /usr/lib/systemd/system/upower.service      2014-11-16 15:26:33.000000000 -0200
+++ /etc/systemd/system/upower.service  2014-12-29 10:16:14.822357371 -0200
@@ -9,8 +9,8 @@
 Restart=on-failure

 [Install]
-# We pull this in by graphical.target instead of waiting for the bus
+# We pull this in by multi-user.target instead of waiting for the bus
 # activation, to speed things up a little: gdm uses this anyway so it is nice
 # if it is already around when gdm wants to use it and doesn't have to wait for
 # it.
-WantedBy=graphical.target
+WantedBy=multi-user.target


1 overridden configuration files found.

Relacionado:
Básico dos arquivos de unidade do systemd
Olho de Cylon do systemd
Ordenação no systemd
systemctl cat/edit
systemctl enable|disable|mask --now
systemctl revert

Comentários

  1. Realmente é muito fácil editar os arquivos em assim. Se fosse em shell script eu acho que não acertaria. =)

    Eu estava procurando exatamente por esse post, pois estava precisando editar o arquivo do gdm.service para remover o conflito com o plymouth-quit. Com esse conflito, eu estava tendo um problema: o Plymouth continuava rodando mesmo após o término da inicialização. Então eu removi o conflito e resolvi o problema. Deve ser uma gambiarra, mas pelo menos foi o jeito que eu achei do Plymouth não ficar rodando eternamente.

    ResponderExcluir
    Respostas
    1. Vai ver é um bug já reportado? Mesmo assim, a configuração de /etc sempre terá prioridade e caso, no futuro, a distribuição atualize o arquivo (em /usr/lib), o systemd continuará interpretando o que existe em /etc até você apagar e rodar systemctl daemon-reload.

      Excluir
    2. Na verdade, eu removi o plymouth-quit.service da linha Conflicts do gdm.service.

      O arquivo upstream do GDM coloca isso na linha Conflicts, porque em modo KMS o próprio GDM faz a administração da transição. Como eu uso um driver de vídeo não-KMS, o GDM não consegue fazer essa transição, e o conflito com o plymouth-quit.service impede que o plymouth-quit seja acionado para matar o Plymouth.

      Excluir
    3. Além disso, eu editei o arquivo e adicionei no After o dkms.service, para que o GDM não inicie antes do DKMS terminar. Como o driver de vídeo está usando DKMS, iniciar o GDM antes da saída do DKMS iria fazer com que o GDM travasse.

      Excluir

Postar um comentário