19 Daemon systemd #

O arquivo de configuração unit contém informações sobre serviço, soquete, dispositivo, ponto de montagem, ponto de montagem automática, arquivo de troca (swap) ou partição, destino de inicialização, caminho do sistema de arquivos monitorado, temporizador controlado e supervisionado pelo systemd, instantâneo de estado do sistema temporário, seção de gerenciamento de recursos ou grupo de processos criados externamente.

O “arquivo unit” é um termo genérico usado pelo systemd para o seguinte:

Para obter mais informações sobre arquivos de unidade do systemd, acesse https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html

Os subcomandos de gerenciamento de serviços são os mesmos usados para gerenciar um serviço com o init do System V (start, stop...). A sintaxe geral dos comandos de gerenciamento de serviços é a seguinte:

O systemd permite gerenciar vários serviços de uma só vez. Em vez de executar os scripts init um após o outro como acontece com o init do System V, execute um comando da seguinte forma:

> sudo systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

Para listar todos os serviços disponíveis no sistema:

> sudo systemctl list-unit-files --type=service

A tabela a seguir lista os comandos de gerenciamento de serviços mais importantes para o systemd e o init do System V:

start

start

stop

stop

restart

restart

try-restart

try-restart

reload

reload

reload-or-restart

n/a

reload-or-try-restart

n/a

status

status

is-active

status

Os comandos de gerenciamento de serviços mencionados na seção anterior permitem manipular serviços na seção atual. O systemd também permite habilitar ou desabilitar serviços permanentemente para serem iniciados automaticamente quando solicitados ou para ficarem sempre indisponíveis. É possível fazer isso com o YaST ou por linha de comando.

19.2.2.1 Habilitando/Desabilitando serviços na linha de comando #

 

A tabela a seguir lista os comandos de habilitação e desabilitação para systemd e o init do System V:

Importante: Inicialização de serviço

Ao habilitar um serviço na linha de comando, ele não é iniciado automaticamente. Ele é programado para iniciar na próxima inicialização do sistema ou mudança de nível de execução/destino. Para iniciar um serviço logo depois de habilitá-lo, execute explicitamente systemctl start MY_SERVICE ou rc MY_SERVICE start.

Tabela 19.2: Comandos para habilitar e desabilitar serviços #

 

Tarefa	Comando systemd	Comando init do System V
Habilitar.	systemctl enable MY_SERVICE(S)	insserv MY_SERVICE(S), chkconfig -a MY_SERVICE(S)
Desabilitar.	systemctl disable MY_SERVICE(S).service	insserv -r MY_SERVICE(S), chkconfig -d MY_SERVICE(S)
Verificar.  Mostra se um serviço está ou não habilitado.	systemctl is-enabled MY_SERVICE	chkconfig MY_SERVICE
Reabilitar.  Semelhante a reiniciar um serviço, este comando primeiro desabilita e depois habilita um serviço. Útil para restaurar um serviço aos seus padrões.	systemctl reenable MY_SERVICE	n/d
Mascarar.  Após “desabilitar” um serviço, ele ainda poderá ser iniciado manualmente. Para desabilitar um serviço, é necessário mascará-lo. Use com cuidado.	systemctl mask MY_SERVICE	n/d
Desmascarar.  Só será possível usar novamente um serviço mascarado depois que ele for desmascarado.	systemctl unmask MY_SERVICE	n/d

Com o init do System V, o sistema era inicializado no chamado “Nível de execução”. O nível de execução define como o sistema é iniciado e quais serviços estão disponíveis no sistema em execução. Os níveis de execução são numerados: os mais conhecidos são 0 (encerramento do sistema), 3 (multiusuário com rede) e 5 (multiusuário com rede e gerenciador de exibição).

O systemd apresenta um novo conceito usando as chamadas “unidades de destino”. No entanto, ele continua totalmente compatível com o conceito de nível de execução. As unidades de destino são nomeadas, e não numeradas, e possuem finalidades específicas. Por exemplo, os destinos local-fs.target e swap.target montam sistemas de arquivos locais e espaços de troca (swap).

O destino graphical.target oferece recursos de sistema multiusuário com rede e gerenciador de exibição e equivale ao nível de execução 5. Destinos complexos, como graphical.target, agem como destinos “meta”, combinando um subconjunto de outros destinos. Como o systemd facilita criar destinos personalizados combinando destinos existentes, ele oferece excelente flexibilidade.

A lista a seguir mostra as unidades de destino mais importantes do systemd. Para ver a lista completa, consulte man 7 systemd.special.

Para continuar compatível com o sistema de nível de execução init do System V, o systemd oferece destinos especiais chamados runlevelX.target que mapeiam os níveis de execução correspondentes numerados X.

Para inspecionar o destino atual, use o comando: systemctl get-default

Importante: systemd ignora /etc/inittab

Os níveis de execução em um sistema init do System V são configurados em /etc/inittab. O systemd não usa essa configuração. Consulte a Seção 19.5.5, “Criando destinos personalizados” para obter instruções sobre como criar seu próprio destino inicializável.

O systemd oferece os meios para a análise dos processos de inicialização do sistema. É possível revisar a lista de todos os serviços e status (em vez de analisar o /var/log/). O systemd permite também explorar o procedimento de inicialização para descobrir quanto tempo leva para inicializar cada serviço.

# systemctl
UNIT                        LOAD   ACTIVE SUB       JOB DESCRIPTION
[...]
iscsi.service               loaded active exited    Login and scanning of iSC+
kmod-static-nodes.service   loaded active exited    Create list of required s+
libvirtd.service            loaded active running   Virtualization daemon
nscd.service                loaded active running   Name Service Cache Daemon
chronyd.service             loaded active running   NTP Server Daemon
polkit.service              loaded active running   Authorization Manager
postfix.service             loaded active running   Postfix Mail Transport Ag+
rc-local.service            loaded active exited    /etc/init.d/boot.local Co+
rsyslog.service             loaded active running   System Logging Service
[...]
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

161 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

# systemctl --failed
UNIT                   LOAD   ACTIVE SUB    JOB DESCRIPTION
apache2.service        loaded failed failed     apache
NetworkManager.service loaded failed failed     Network Manager
plymouth-start.service loaded failed failed     Show Plymouth Boot Screen

[...]

systemd.log_level=debug systemd.log_target=kmsg

> dmesg -T | less

O systemd é compatível com o System V, o que ainda permite usar os scripts init existentes do System V. Entretanto, há pelo menos um problema conhecido em que o script init do System V não funciona com o systemd pronto para uso: iniciar um serviço como outro usuário por meio de su ou sudo nos scripts init resulta em falha do script, gerando um erro de “Acesso negado”.

Ao mudar o usuário com su ou sudo, é iniciada uma sessão PAM. Essa sessão será terminada após a conclusão do script init. Como consequência, o serviço que foi iniciado pelo script init também é terminado. Para solucionar esse erro, faça o seguinte:

Os arquivos de unidade do systemd oferecidos pela SUSE são armazenados em /usr/lib/systemd/. Os arquivos de unidade personalizados e os drop-ins de arquivo de unidade são armazenados em /etc/systemd/.

Atenção: Impedindo que sua personalização seja sobregravada

Ao personalizar o systemd, sempre use o diretório /etc/systemd/ em vez de /usr/lib/systemd/. Do contrário, as mudanças serão sobregravadas na próxima atualização do systemd.

Os arquivos drop-in (ou drop-ins) são arquivos de unidade parciais que substituem apenas configurações específicas do arquivo de unidade. Os drop-ins têm prioridade sobre os arquivos de configuração principais. O comando systemctl edit SERVICE inicia o editor de texto padrão e cria um diretório com um arquivo override.conf vazio em /etc/systemd/system/NAME.service.d/. O comando também garante que o processo systemd em execução seja notificado sobre as mudanças.

Por exemplo, para mudar a quantidade de tempo que o sistema espera até o MariaDB ser iniciado, execute sudo systemctl edit mariadb.service e edite o arquivo aberto para incluir apenas as linhas modificadas:

# Configures the time to wait for start-up/stop
TimeoutSec=300

Ajuste o valor TimeoutSec e grave as mudanças. Para habilitar as mudanças, execute sudo systemctl daemon-reload.

Para obter mais informações, consulte as páginas de manual que podem ser chamadas com o comando man 1 systemctl.

Atenção: Criar uma cópia de um arquivo de unidade completo

Se você usar a opção --full no comando systemctl edit --full SERVICE, será criada uma cópia do arquivo de unidade original, no qual poderá modificar opções específicas. Não recomendamos essa personalização porque, quando o arquivo de unidade é atualizado pela SUSE, suas mudanças são substituídas pela cópia personalizada no diretório /etc/systemd/system/. Além disso, se a SUSE disponibilizar atualizações para drop-ins de distribuição, elas substituirão a cópia do arquivo de unidade criado com --full. Para evitar esse tipo de confusão e manter sua personalização válida, use os drop-ins.

Além de usar o comando systemctl edit, você pode criar drop-ins manualmente para ter mais controle sobre a prioridade deles. Esses drop-ins permitem estender os arquivos de configuração da unidade e do daemon sem ter que editar ou substituir os próprios arquivos. Eles estão armazenados nos seguintes diretórios:

Dica

Consulte a página de manual man 5 systemd.unit para obter a lista completa de caminhos de pesquisa de unidade.

Por exemplo, para desabilitar a limitação de taxa imposta pela configuração padrão do systemd-journald, siga estas etapas:

Nota: Evitando conflitos de nome

Para evitar conflitos de nome entre os drop-ins e os arquivos fornecidos pela SUSE, é recomendado prefixar todos os drop-ins com um número de dois dígitos e um traço, por exemplo, 80-override.conf.

As seguintes faixas são reservadas:

• 0-19 é reservada para upstream do. systemd.

• 20-29 é reservada para o systemd fornecido pela SUSE.

• 30-39 é reservada para pacotes da SUSE diferentes do systemd.

• 40-49 é reservada para pacotes de terceiros.

• 50 é reservada para arquivos de unidade drop-in criados com systemctl set-property.

Use um número de dois dígitos acima dessa faixa para garantir que nenhum dos arquivos drop-in fornecidos pela SUSE substitua os seus próprios drop-ins.

Dica

Você pode usar systemctl cat $UNIT para listar e verificar quais arquivos são levados em consideração na configuração das unidades.

Dica

Como a configuração dos componentes do systemd pode estar distribuída por diferentes locais no sistema de arquivos, talvez seja difícil obter uma visão geral global. Para inspecionar a configuração de um componente do systemd, use os seguintes comandos:

• systemctl cat UNIT_PATTERN imprime arquivos de configuração relacionados a uma ou mais unidades do systemd, por exemplo:

  > systemctl cat atd.service

• systemd-analyze cat-config DAEMON_NAME_OR_PATH copia o conteúdo de um arquivo de configuração e dos drop-ins para um daemon do systemd, por exemplo:

  > systemd-analyze cat-config systemd/journald.conf

Desde o lançamento do SUSE Linux Enterprise Desktop 15, a infraestrutura do xinetd foi removida. Esta seção descreve como converter arquivos existentes de serviço do xinetd em soquetes do systemd.

Para cada arquivo de serviço do xinetd, você precisa de pelo menos dois arquivos de unidade do systemd: o arquivo de soquete (*.socket) e um arquivo de serviço associado (*.service). O arquivo de soquete informa ao systemd qual soquete criar, e o arquivo de serviço informa ao systemd qual executável iniciar.

Considere o seguinte arquivo de serviço do xinetd de exemplo:

# cat /etc/xinetd.d/example
service example
{
  socket_type = stream
  protocol = tcp
  port = 10085
  wait = no
  user = user
  group = users
  groups = yes
  server = /usr/libexec/example/exampled
  server_args = -auth=bsdtcp exampledump
  disable = no
}

Para convertê-lo em systemd, você precisa dos dois arquivos correspondentes a seguir:

# cat /usr/lib/systemd/system/example.socket
[Socket]
ListenStream=0.0.0.0:10085
Accept=false

[Install]
WantedBy=sockets.target

# cat /usr/lib/systemd/system/example.service
[Unit]
Description=example

[Service]
ExecStart=/usr/libexec/example/exampled -auth=bsdtcp exampledump
User=user
Group=users
StandardInput=socket

Para obter uma lista completa das opções de arquivo de systemd “soquete” e “serviço”, consulte as páginas de manual do systemd.socket e do systemd.service (man 5 systemd.socket e man 5 systemd.service).

Nos sistemas init SUSE do System V, o nível de execução 4 não costuma ser usado para permitir que administradores criem sua própria configuração de nível de execução. O systemd permite criar qualquer número de destinos personalizados. A sugestão é começar adaptando um destino existente, como graphical.target.

O systemd suporta a limpeza de diretórios temporários regularmente. A configuração da versão do sistema anterior é automaticamente migrada e ativada. tmpfiles.d, que é responsável pelo gerenciamento de arquivos temporários, lê a configuração dos arquivos /etc/tmpfiles.d/*.conf, /run/tmpfiles.d/*.conf e /usr/lib/tmpfiles.d/*.conf. A configuração armazenada no /etc/tmpfiles.d/*.conf anula as configurações relacionadas dos outros dois diretórios (/usr/lib/tmpfiles.d/*.conf é o local onde os pacotes armazenam seus arquivos de configuração).

O formato da configuração é de uma linha por caminho incluindo ação e caminho; e, opcionalmente, modo, propriedade e os campos de idade e argumento, dependendo da ação. O exemplo a seguir desvincula os arquivos de bloqueio do X11:

Type Path               Mode UID  GID  Age Argument
r    /tmp/.X[0-9]*-lock

Para obter o status do temporizador tmpfile:

> sudo systemctl status systemd-tmpfiles-clean.timer
systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
 Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
 Active: active (waiting) since Tue 2018-04-09 15:30:36 CEST; 1 weeks 6 days ago
   Docs: man:tmpfiles.d(5)
         man:systemd-tmpfiles(8)

Apr 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories.
Apr 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.

Para obter mais informações sobre como lidar com os arquivos temporários, consulte man 5 tmpfiles.d.

A Seção 19.6.9, “Depurando serviços” explica como ver mensagens de registro de determinado serviço. No entanto, a exibição de mensagens de registro não se restringe a registros de serviços. É possível também acessar e consultar as mensagens de registro completas gravadas pelo systemd, o chamado “Diário”. Use o comando journalctl para exibir as mensagens de registro completas começando pelas entradas mais antigas. Consulte man 1 journalctl para ver as opções. Por exemplo, aplicação de filtros ou mudança do formato de saída.

É possível gravar o estado atual do systemd em um instantâneo nomeado e depois revertê-lo para esse estado usando o subcomando isolate. Isso é útil para testar serviços ou destinos personalizados, pois permite retornar para um estado definido a qualquer momento. Um instantâneo só fica disponível na sessão atual e é apagado automaticamente na reinicialização. O nome do instantâneo deve terminar com .snapshot.

Com o systemd, é possível carregar os módulos do kernel automaticamente no momento da inicialização, usando o arquivo de configuração em /etc/modules-load.d. O arquivo deve ser nomeado MODULE.conf e ter o seguinte conteúdo:

# load module MODULE at boot time
MODULE

Se um pacote instalar um arquivo de configuração para carregar um módulo do kernel, o arquivo será instalado em /usr/lib/modules-load.d. Se houver dois arquivos de configuração com o mesmo nome, aquele em /etc/modules-load.d terá precedência.

Para obter mais informações, consulte a página de manual de modules-load.d(5).

Com o System V, as ações init que precisam ser executadas antes de carregar um serviço tinham que ser especificadas em /etc/init.d/before.local . Esse procedimento não é mais suportado com o systemd. Se você precisa executar ações antes de iniciar serviços, faça o seguinte:

Em um sistema init tradicional do System V, nem sempre é possível corresponder um processo ao serviço que o gerou. Alguns serviços, como o Apache, geram diversos processos de terceiros (por exemplo, CGI ou Java) que, por sua vez, geram mais processos. Isso dificulta ou até impossibilita uma atribuição clara. Além do mais, um serviço pode não ser terminado corretamente, deixando alguns filhos ativos.

O systemd resolve este problema colocando cada serviço em seu próprio grupo de controle (cgroup). Cgroups são recursos do kernel que possibilitam agregar processos e todos os seus filhos em grupos hierárquicos organizados. O systemd nomeia cada cgroup de acordo com seu serviço. Como um processo não privilegiado não pode “deixar” seu cgroup, essa é uma forma eficiente de rotular todos os processos gerados por um serviço com o nome do serviço.

Para listar todos os processos pertencentes a um serviço, use o comando systemd-cgls, por exemplo:

# systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│   ├─session-102.scope
│   │ ├─12426 gdm-session-worker [pam/gdm-password]
│   │ ├─15831 gdm-session-worker [pam/gdm-password]
│   │ ├─15839 gdm-session-worker [pam/gdm-password]
│   │ ├─15858 /usr/lib/gnome-terminal-server

[...]

└─system.slice
  ├─systemd-hostnamed.service
  │ └─17616 /usr/lib/systemd/systemd-hostnamed
  ├─cron.service
  │ └─1689 /usr/sbin/cron -n
  ├─postfix.service
  │ ├─ 1676 /usr/lib/postfix/master -w
  │ ├─ 1679 qmgr -l -t fifo -u
  │ └─15590 pickup -l -t fifo -u
  ├─sshd.service
  │ └─1436 /usr/sbin/sshd -D

[...]

Consulte o Chapter 10, Kernel control groups para obter mais informações sobre os cgroups.

Conforme explicado na Seção 19.6.6, “Grupos de controle (cgroups) do kernel”, nem sempre é possível atribuir um processo a seu processo de serviço pai em um sistema init do System V. Isso dificulta parar um serviço e os respectivos filhos. Os processos filhos que não forem terminados permanecerão como processos zumbis.

O conceito do systemd de confinar cada serviço em um cgroup possibilita identificar todos os processos filhos de um serviço e, portanto, permite enviar um sinal a cada um desses processos. Use systemctl kill para enviar sinais aos serviços. Para ver uma lista dos sinais disponíveis, consulte man 7 signals.

O serviço D-Bus é o barramento de mensagem para comunicação entre clientes systemd e o gerenciador systemd que está sendo executado como pid 1. Embora o dbus seja um daemon independente, ele é parte integrante da infraestrutura do init.

Parar ou reiniciar o dbus no sistema em execução é semelhante a uma tentativa de parar ou reiniciar o PID 1. Esse procedimento interrompe a comunicação entre cliente/servidor do systemd e inutiliza a maioria das funções do systemd.

Portanto, terminar ou reiniciar o dbus não é recomendado nem suportado.

A atualização do dbus ou dos pacotes relacionados ao dbus requer uma reinicialização. Quando estiver em dúvida se uma reinicialização é necessária, execute o comando sudo zypper ps -s. Se dbus aparecer entre os serviços listados, será necessário reinicializar o sistema.

Saiba que o dbus é atualizado mesmo quando as atualizações automáticas estão configuradas para ignorar os pacotes que exigem reinicialização.

Por padrão, o systemd não é muito verboso. Se um serviço foi iniciado com êxito, nenhuma saída é gerada. Em caso de falha, uma breve mensagem de erro é exibida. No entanto, systemctl status oferece um meio para depurar a inicialização e a operação de um serviço.

O systemd já vem com um mecanismo de registro (“The Journal” — O Diário) que registra as mensagens do sistema. Isso permite exibir as mensagens de serviço juntamente com as mensagens de status. O comando status funciona de forma parecida com tail e também exibe as mensagens de registro em formatos diferentes, o que faz dele uma poderosa ferramenta de depuração.

As unidades do temporizador podem usar temporizadores monotônicos e em tempo real.

Cada unidade do temporizador deve ter um arquivo de unidade do systemd correspondente que ela controla. Em outras palavras, um arquivo .timer ativa e gerencia o arquivo .service correspondente. Quando usado com um temporizador, o arquivo .service não requer uma seção [Install], já que o serviço é gerenciado pelo temporizador.

Para entender os conceitos básicos das unidades do temporizador do systemd, configuramos um temporizador que aciona o script shell foo.sh.

A primeira etapa é criar uma unidade de serviço do systemd que controle o script shell. Para fazer isso, abra um novo arquivo de texto para edição e adicione a seguinte definição de unidade de serviço:

[Unit]
Description="Foo shell script"

[Service]
ExecStart=/usr/local/bin/foo.sh

Grave o arquivo com o nome foo.service no diretório /etc/systemd/system/.

Em seguida, abra um novo arquivo de texto para edição e adicione a seguinte definição do temporizador:

[Unit]
Description="Run foo shell script"

[Timer]
OnBootSec=5min
OnUnitActiveSec=24h
Unit=foo.service

[Install]
WantedBy=multi-user.target

A seção [Timer] no exemplo acima especifica qual serviço acionar (foo.service) e quando acioná-lo. Nesse caso, a opção OnBootSec especifica um temporizador monotônico que aciona o serviço cinco minutos após o boot do sistema, enquanto a opção OnUnitActiveSec aciona o serviço 24 horas após a ativação do serviço (ou seja, o temporizador aciona o serviço uma vez por dia). Por fim, a opção WantedBy especifica que o temporizador deve ser iniciado quando o sistema atingiu o destino multiusuário.

Em vez de um temporizador monotônico, você pode especificar um em tempo real usando a opção OnCalendar. A seguinte definição do temporizador em tempo real aciona a unidade de serviço relacionada uma vez por semana, começando na segunda-feira às 12:00.

[Timer]
OnCalendar=weekly
Persistent=true

A opção Persistent=true indica que o serviço será acionado logo após a ativação do temporizador, se o temporizador tiver perdido o último horário de início (por exemplo, porque o sistema estava desligado).

A opção OnCalendar também pode ser usada para definir horários e datas específicos para acionar um serviço usando o seguinte formato: DayOfWeek Year-Month-Day Hour:Minute:Second. O exemplo abaixo aciona um serviço às 5:00 todos os dias:

OnCalendar=*-*-* 5:00:00

Você pode usar um asterisco para especificar qualquer valor e vírgulas para listar os valores possíveis. Use dois valores separados por .. para indicar uma faixa contígua. O exemplo a seguir aciona um serviço às 18:00 todas as sextas-feiras do mês:

OnCalendar=Fri *-*-1..7 18:00:00

Para acionar um serviço em horários diferentes, você pode especificar várias entradas OnCalendar:

OnCalendar=Mon..Fri 10:00
OnCalendar=Sat,Sun 22:00

No exemplo acima, um serviço é acionado às 10h nos dias de semana e às 22h nos fins de semana.

Quando você terminar de editar o arquivo de unidade do temporizador, grave-o com o nome foo.timer no diretório /etc/systemd/system/. Para verificar se os arquivos de unidade criados estão corretos, execute o seguinte comando:

> sudo  systemd-analyze verify /etc/systemd/system/foo.*

Se o comando não retornar nenhuma saída, os arquivos foram aprovados na verificação.

Para iniciar o temporizador, use o comando sudo systemctl start foo.timer. Para habilitar o temporizador na inicialização, execute o comando sudo systemctl enable foo.timer.

Como os temporizadores são tratados como unidades regulares do systemd, você pode gerenciá-los usando o systemctl. Você pode iniciar um temporizador com systemctl start, habilitá-lo com systemctl enable e assim por diante. Além disso, você pode listar todos os temporizadores ativos usando o comando systemctl list-timers. Para listar todos os temporizadores, incluindo os inativos, execute o comando systemctl list-timers --all.