O systemd é um gerenciador de sistema e sessão para Linux, compatível com os scripts init do System V e do LSB. Os principais recursos são:

O arquivo de configuração unit codifica as informações sobre serviço, soquete, dispositivo, ponto de montagem, ponto de automount, arquivo de troca 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 o systemd.unit, consulte 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, etc.). 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:

systemctl start <my_1st_service>.service <my_2nd_service>.service

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

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.

11.2.2.1 Habilitar/Desabilitar 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 após ele ter sido habilitado, execute systemctl start <meu_serviço>.service ou rc<meu_serviço> start explicitamente.

Tabela 11.2 Comandos para habilitar e desabilitar serviços #

Tarefa	Comando systemd	Comando init do System V
Habilitando.	systemctl enable <meu(s)_serviço(s)>.service	insserv <meu(s)_serviço(s)>
Desabilitar.	systemctl disable <meu(s)_serviço(s)>.service	insserv -r <meu(s)_serviço(s)>
Verificar.  Mostra se um serviço está ou não habilitado.	systemctl is-enabled <meu_serviço>.service	n/d
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 <meu_serviço>.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 <meu_serviço>.service	n/d
Desmascarar.  Só será possível usar novamente um serviço mascarado depois que ele for desmascarado.	systemctl unmask <meu_serviço>.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 mapeados a níveis de execução correspondentes numerados X.

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

Importante: O systemd ignora o /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 11.5.3, “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 de forma prática (sem ter que analisar o /varlog/). O systemd permite também explorar o procedimento de inicialização para descobrir quanto tempo leva para inicializar cada serviço.

root # systemctl
UNIT                                LOAD   ACTIVE SUB       JOB DESCRIPTION
[...]
systemd-random-seed-load.path       loaded active waiting       Random Seed
acpid.service                       loaded active running       ACPI Event Daemon
apache2.service                     loaded failed failed        apache
avahi-daemon.service                loaded active running       Avahi mDNS/DNS-SD Stack
bluez-coldplug.service              loaded active exited        LSB: handles udev coldplug of bluetooth dongles
console-kit...-system-start.service loaded active exited        Console System Startup Logging
cron.service                        loaded active running       Command Scheduler
cups.service                        loaded active running       CUPS Printing 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.
JOB    = Pending job for the unit.

107 units listed. Pass --all to see inactive units, too.

root # 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:

Os arquivos de serviço do systemd estão localizados em /usr/lib/systemd/system. Para personalizá-los, faça o seguinte:

Os arquivos modificados em /etc/systemd terão prioridade sobre os arquivos originais em /usr/lib/systemd/system, desde que seus nomes sejam iguais.

Para adicionar apenas algumas linhas a um arquivo de configuração ou modificar uma pequena parte dele, é possível usar os chamados arquivos “dropin”. 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 no serviço foobar localizado em /usr/lib/systemd/system/ foobar.service, faça o seguinte:

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.

A Seção 11.6.6, “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 systemd-journalctl para exibir as mensagens de registro completas com as entradas antigas. Consulte man 1 systemd-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

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

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 terminar 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):

root # 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
  ├─ntpd.service
  │ └─1328 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf
  ├─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 8, Kernel Control Groups, System Analysis and Tuning Guide para obter mais informações sobre os cgroups.

Conforme explicado na Seção 11.6.4, “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 terminar 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 claramente 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.

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.