19 Daemon systemd #

O arquivo de configuração unit contém informações sobre serviço, soquete, dispositivo, ponto de montagem, ponto de automount, 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, fraçã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 http://www.freedesktop.org/software/systemd/man/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 pelo systemd e pelo 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 completamente, é 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.

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 saber 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.4, “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 os respectivos 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 out-of-the-box: 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 será terminado. Para solucionar esse erro, faça o seguinte:

A maneira recomendada de personalizar arquivos unit é usar o comando systemctl edit SERVICE. Esse comando inicia o editor de texto padrão e cria um diretório com o arquivo override.conf 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.

Se preferir, você poderá abrir uma cópia do arquivo original para edição em vez de um arquivo em branco executando systemctl edit --full SERVICE. Ao editar o arquivo, não remova nenhuma das seções existentes.

Como exercício, mude por quanto tempo o sistema aguarda pela inicialização do MariaDB. Como root, execute systemctl edit --full mariadb.service. O arquivo aberto terá aparência similar à seguinte:

[Unit]
Description=MySQL server
Wants=basic.target
Conflicts=mariadb.target
After=basic.target network.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service

[Service]
Restart=on-abort
Type=notify
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  install
ExecStartPre=/usr/lib/mysql/mysql-systemd-helper  upgrade
ExecStart=/usr/lib/mysql/mysql-systemd-helper     start

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

# Prevent writes to /usr, /boot, and /etc
ProtectSystem=full

# Prevent accessing /home, /root and /run/user
ProtectHome=true

UMask=007

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

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

Para pequenas mudanças de um arquivo de configuração, use os chamados arquivos drop-in. Esses arquivos permitem estender a configuração dos arquivos de unidade sem ter que editá-los ou anulá-los realmente.

Por exemplo, para mudar um valor único no serviço FOOBAR localizado em /usr/lib/systemd/system/FOOBAR.SERVICE, faça o seguinte:

Nota: Evitando conflitos de nome

Para evitar conflitos de nome entre os arquivos drop-in e os arquivos fornecidos pelo SUSE, é recomendável prefixar todos os nomes de arquivos drop-in 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-25 é reservada para o systemd fornecido pelo SUSE

• 26-29 é reservada para pacotes do SUSE (diferentes do systemd)

• 50 é reservada para arquivos 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 pelo SUSE anule os seus próprios arquivos drop-in.

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

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 de “serviço”, consulte as páginas de manual do systemd.socket e do systemd.service (man 5 systemd.socket, 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. O tmpfiles.d, que é responsável por gerenciar arquivos temporários, lê a configuração nos 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 mais tarde revertê-lo com 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 atribuir claramente um processo ao serviço que o gerou. Alguns serviços, como o Apache, geram diversos processos de terceiros (por exemplo, processos 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. O resultado será parecido com o seguinte exemplo (resumido):

# 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 todos os seus 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.

Terminar ou reiniciar o dbus no sistema em execução é semelhante a uma tentativa de terminar ou reiniciar o pid 1. Isso interromperá a comunicação entre cliente e servidor systemd e inutilizará 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 for iniciado com êxito, nenhuma saída será gerada. Em caso de falha, uma breve mensagem de erro será exibida. Porém, o systemctl status oferece os meios de depurar a inicialização e 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 o comando 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, o 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 acionará o serviço uma vez por dia). Por fim, a opção WantedBy especifica que o temporizador deve ser iniciado quando o sistema atingir o destino de multiusuários.

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 10:00 nos dias da semana e às 22:00 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, habilitar um temporizador 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.