Modificar parâmetros dos arquivos de unidade do systemd
O gerenciador de pacotes coloca os arquivos de unidade na pasta
Arquivos com o mesmo nome em
Também é possível usar a diretiva
A partir do systemd 198, são suportados arquivos drop-in de configuração no diretório
Depois, dentro d o diretório, criar um (ou mais) arquivo
Não sendo necessário usar
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
/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
Realmente é muito fácil editar os arquivos em assim. Se fosse em shell script eu acho que não acertaria. =)
ResponderExcluirEu 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.
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.
ExcluirNa verdade, eu removi o plymouth-quit.service da linha Conflicts do gdm.service.
ExcluirO 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.
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