sexta-feira, 26 de abril de 2013

Modificar parâmetros de arquivos .service

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

# cp /usr/lib/systemd/system/<nome>.service /etc/systemd/system
# nano /etc/systemd/system/<nome>.service
# 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 alterarmos, por exemplo, a prioridade de escalonamento de determinado daemon:

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

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

[Service]
Nice=-7

A partir do systemd 198, são suportados arquivos "drop-in" de configuração na pasta /etc/systemd/system/<nome>.service.d (precisa ser criada de acordo com o nome do daemon). Qualquer arquivo com a extensão .conf será interpretado e aplicado sobre os valores configurados no .service presente em /usr.

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

Depois, dentro da pasta, criar um (ou mais) arquivo .conf contendo a configuração desejada.

/etc/systemd/system/<nome>.service.d/croassaint.conf

[Service]
Nice=-7

Não sendo necessário usar .include.

Precisamos dizer para o systemd reler os arquivos e depois reiniciar o daemon para os seus processos serem iniciados com a nova prioridade:

# systemctl daemon-reload
# systemctl restart <nome>.service

O systemd 201 refina mais e exibe na saída de systemctl status os arquivos "drop-in":
(usando nginx.service)

# systemctl status nginx.service
nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)
  Drop-In: /etc/systemd/system/nginx.service.d
           └─croassaint.conf
   Active: active (running) since Sex 2013-04-26 15:23:53 FNT; 3min 56s ago
 Main PID: 3438 (nginx)
   CGroup: name=systemd:/system/nginx.service
           ├─3438 nginx: master process /usr/sbin/ngin
           └─3439 nginx: worker proces

Vamos conferir se o valor de "Nice=" foi interpretado:

# systemctl -p Nice show nginx.service
Nice=-7

E se está de fato aplicado:

# ps -eo ni,comm,args | grep '[n]ginx'
 -7 nginx           nginx: master process /usr/sbin/nginx
 -7 nginx           nginx: worker process

Tudo OK.

Para mais opções ver systemd.exec, systemd.kill, systemd.service, systemd.unit.

[Atualização - 16/12/2013] Pequena melhoria.

[Atualização - 01/01/2015] systemd-delta (183) é útil para dar um panorama do que está sendo substituído. Exemplo:

# 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.

4 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