Systemd
é um sistema init e gerenciador de sistema que se tornou o novo padrão para distribuições Linux. Devido à sua forte adoção, familiarizar-se com o systemd
vale muito a pena, pois irá tornar a administração de servidores consideravelmente mais fácil. Aprender sobre as ferramentas e daemons que compõem o systemd
e como usá-los irá ajudar a entender melhor o poder, flexibilidade e capacidades que ele oferece ou, pelo menos, facilitará o seu trabalho.
Neste guia, vamos discutir o comando systemctl
, que é a ferramenta de gerenciamento central para controlar o sistema init. Vamos abordar como gerenciar serviços, verificar status, alterar estados de sistema e trabalhar com os arquivos de configuração.
Observe que embora o systemd
tenha se tornado o sistema init padrão para muitas distribuições Linux, ele não é implementado universalmente em todas as distros. À medida que você percorrer este tutorial, se o seu terminal exibir o erro bash: systemctl is not installed
, então é provável que sua máquina tenha um sistema init diferente instalado.
O objetivo fundamental de um sistema init é inicializar os componentes que devem ser iniciados após o kernel do Linux ser inicializado (tradicionalmente conhecido como componentes “userland”). O sistema init também é usado para gerenciar serviços e daemons para o servidor em qualquer momento enquanto o sistema está em execução. Com isso em mente, vamos começar com algumas operações básicas de gerenciamento de serviços.
No systemd
, o alvo da maioria das ações são “unidades”, que são os recursos que o systemd
sabe gerenciar. As unidades são categorizadas pelo tipo de recurso que representam e são definidas com arquivos conhecidos como arquivos unit. O tipo de cada unidade pode ser inferido a partir do sufixo no final do arquivo.
Para tarefas de gerenciamento de serviços, a unidade de destino serão unidades de serviço, que possuem arquivos de unidade com um sufixo .service
. No entanto, para a maioria dos comandos de gerenciamento de serviços, é possível deixar o sufixo .service
, pois o systemd
é inteligente o suficiente para saber que você provavelmente deseja operar em um serviço ao usar comandos de gerenciamento de serviços.
Para iniciar um serviço systemd
, executando instruções no arquivo de unidade do serviço, use o comando start
. Caso esteja usando um usuário não root, você terá que usar o sudo
, pois isso afetará o estado do sistema operacional:
- sudo systemctl start application.service
Como mencionamos acima, o systemd
sabe procurar por arquivos *.service
para comandos de gerenciamento de serviços, de forma que o comando poderia ser também digitado desta forma:
- sudo systemctl start application
Embora você possa usar o formato acima para a administração geral, para maior clareza, vamos usar o sufixo .service
para o resto dos comandos, para sermos explícitos sobre o alvo em que estamos operando.
Para parar um serviço que esteja atualmente em execução, use o comando stop
:
- sudo systemctl stop application.service
Para reiniciar um serviço em execução, use o comando restart
:
- sudo systemctl restart application.service
Se o aplicativo em questão for capaz de recarregar seus arquivos de configuração (sem reiniciar), você pode emitir o comando reload
para iniciar esse processo:
- sudo systemctl reload application.service
Se não tiver certeza se o serviço possui a funcionalidade para recarregar sua configuração, emita o comando reload-or-restart
. Isso irá recarregar a configuração em vigor, se disponível. Caso contrário, o serviço será reiniciado para que a nova configuração seja ativada:
- sudo systemctl reload-or-restart application.service
Os comandos acima são úteis para iniciar ou interromper serviços durante a sessão atual. Para dizer ao systemd
para iniciar serviços automaticamente na inicialização do sistema, é necessário habilitá-los.
Para iniciar um serviço na inicialização, use o comando enable
:
- sudo systemctl enable application.service
Isso irá criar um link simbólico a partir da cópia do arquivo de serviço do sistema (geralmente em /lib/systemd/system
ou /etc/systemd/system
) para a localização em disco onde o systemd
procura por arquivos de inicialização automática (geralmente etc/systemd/system/some_target.target.wants
. Vamos abordar o que é um alvo mais adiante neste guia).
Para impedir que o serviço seja iniciado automaticamente, digite:
- sudo systemctl disable application.service
Isso irá remover o link simbólico que indica que o serviço deve ser iniciado automaticamente.
Esteja ciente de que habilitar um serviço não o inicia na sessão atual. Se quiser iniciar o serviço e também habilitá-lo na inicialização, será necessário emitir ambos os comandos start
e enable
.
Para verificar o status de um serviço em seu sistema, use o comando status
:
- systemctl status application.service
Isso irá mostrar-lhe o estado do serviço, a hierarquia de cgroup e as primeiras linhas de registro.
Por exemplo, ao verificar o status de um servidor Nginx, pode ser que você veja um resultado como este:
Output● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
Main PID: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
└─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server...
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.
Isso oferece uma visão geral interessante do status atual do aplicativo, notificando você acerca de qualquer problema ou ação que possa ser necessária.
Há também métodos para verificar por estados específicos. Por exemplo, para verifciar se uma unidade está ativa (em execução), use o comando is-active
:
- systemctl is-active application.service
Isso irá retornar o estado da unidade atual, que geralmente é active
ou inactive
. O código de saída será “0” se for ativo, tornando o resultado mais simples de se analisar em scripts do shell.
Para ver se uma unidade está habilitada, use o comando is-enabled
:
- systemctl is-enabled application.service
Isso irá mostrar se o serviço está enabled
ou disabled
e irá definir novamente o código de saída como “0” ou “1”, dependendo da resposta para a pergunta do comando.
Uma terceira verificação é se a unidade está em um estado de falha. Ele indica se houve um problema ao iniciar a unidade em questão:
- systemctl is-failed application.service
Isso irá retornar active
se a unidade estiver executando corretamente ou failed
caso um erro tenha ocorrido. Se a unidade tiver sido intencionalmente interrompida, ela pode retornar unknown
ou inactive
. Um status de saída de “0” indica que uma falha ocorreu, enquanto um status de saída de “1” indica qualquer outro status.
Os comandos mostrados até agora têm sido úteis para o gerenciamento de serviços únicos, mas não são muito úteis para explorar o estado atual do sistema. Existem diversos comandos do systemctl
que fornecem essa informação.
Para ver uma lista com todas as unidades ativas das quais o systemd
sabe, podemos usar o comando list-units
:
- systemctl list-units
Isso irá mostrar-lhe uma lista de todas as unidades que o systemd
possui como ativa atualmente no sistema. O resultado se parecerá com este:
OutputUNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running ATD daemon
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack
dbus.service loaded active running D-Bus System Message Bus
dcron.service loaded active running Periodic Command Scheduler
dkms.service loaded active exited Dynamic Kernel Modules System
getty@tty1.service loaded active running Getty on tty1
. . .
O resultado possui as seguintes colunas:
systemd
systemd
. A configuração de unidades carregadas é mantida na memória.Como o comando list-units
mostra apenas unidades ativas por padrão, todas as entradas acima exibirão loaded
na coluna LOAD e active
na coluna ACTIVE. Essa exibição é na verdade o comportamento padrão do systemctl
quando chamado sem comandos adicionais. Sendo assim, você irá ver a mesma coisa se chamar systemctl
sem argumentos:
- systemctl
Podemos dizer ao systemctl
para mostrar outras informações adicionando sinalizadores adicionais. Por exemplo, para ver todas as unidades que o systemd
carregou (ou tentou carregar), independentemente se estão ou não ativas, use o sinalizador --all
, desta forma:
- systemctl list-units --all
Isso irá mostrar qualquer unidade que o systemd
carregou ou tentou carregar, independentemente do seu estado atual no sistema. Algumas unidades tornam-se inativas após serem executadas, e algumas unidades que o systemd
tentou carregar podem não ter sido encontradas em disco.
Use outros sinalizadores para filtrar esses resultados. Por exemplo, é possível usar o sinalizador --state=
para indicar os estados LOAD, ACTIVE ou SUB que desejamos ver. Será necessário manter o sinalizador --all
para que o systemctl
permita que unidades não ativas sejam exibidas:
- systemctl list-units --all --state=inactive
Outro filtro comum é o filtro --type=
. Podemos dizer ao systemctl
para exibir apenas unidades do tipo em que estamos interessados. Por exemplo, para ver apenas unidades de serviço ativas, podemos usar:
- systemctl list-units --type=service
O comando list-units
exibe apenas unidades que o systemd
tentou analisar e carregar na memória. Como o systemd
irá ler apenas unidades as quais ele acha necessário, isso não incluirá necessariamente todas as unidades disponíveis no sistema. Para ver todos os arquivos de unidade disponíveis nos caminhos do systemd
, incluindo aquelas que o systemd
não tentou carregar, use o comando list-unit-files
:
- systemctl list-unit-files
As unidades são representações de recursos sobre os quais o systemd
sabe. Como o systemd
não leu necessariamente todas as definições de unidade nesta visão, ele apresenta apenas informações sobre os arquivos em si. O resultado possui duas colunas: o arquivo de unidade e o estado.
OutputUNIT FILE STATE
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount static
var-lib-nfs-rpc_pipefs.mount static
org.cups.cupsd.path enabled
. . .
O estado normalmente será enabled
, disabled
, static
ou masked
. Neste contexto, estático significa que o arquivo de unidade não contém uma seção install
, que é usada para habilitar uma unidade. Dessa forma, essas unidades não podem ser ativadas. Geralmente, isso significa que a unidade executa uma ação única ou é usada apenas como uma dependência de outra unidade e não deve ser executada sozinha.
Vamos abordar o que masked
significa daqui a pouco.
Até aqui, estivemos trabalhando com serviços e exibindo informações sobre a unidade e arquivos de unidade sobre os quais o systemd
sabe. No entanto, é possível descobrir mais informações específicas sobre unidades usando alguns comandos adicionais.
Para exibir o arquivo de unidade que o systemd
carregou em seu sistema, use o comando cat
(adicionado na versão 209 do systemd
). Por exemplo, para ver o arquivo de unidade do daemon de planejamento atd
, poderíamos digitar:
- systemctl cat atd.service
Output[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target
O resultado é o arquivo de unidade, da forma como é conhecido pelo processo do systemd
atualmente em execução. Isso pode ser importante se você tiver arquivos de unidade modificados recentemente ou se estiver sobrepondo certas opções em um fragmento de arquivo de unidade (vamos falar disso mais tarde).
Para ver a árvore de dependências de uma unidade, use o comando list-dependencies
:
- systemctl list-dependencies sshd.service
Isso irá exibir uma hierarquia mapeando as dependências que devem ser tratadas para iniciar a unidade em questão. Dependências, neste contexto, incluem aquelas unidades que são exigidas ou procuradas pelas unidades acima dela.
Outputsshd.service
├─system.slice
└─basic.target
├─microcode.service
├─rhel-autorelabel-mark.service
├─rhel-autorelabel.service
├─rhel-configure.service
├─rhel-dmesg.service
├─rhel-loadmodules.service
├─paths.target
├─slices.target
. . .
As dependências recursivas são exibidas apenas para unidades .target
, que indicam estados do sistema. Para listar recursivamente todas as dependências, inclua o sinalizador --all
.
Para mostrar dependências reversas (unidades que dependem da unidade especificada), adicione o sinalizador --reverse
ao comando. Outros sinalizadoras que são úteis são os sinalizadoras --before
e --after
, que podem ser usados para mostrar unidades que dependem da unidade especificada iniciando antes e depois de si mesmos, respectivamente.
Para ver as propriedades de baixo nível de uma unidade, use o comando show
. Ele irá exibir uma lista de propriedades que são definidas para a unidade especificada usando um formato key=value
:
- systemctl show sshd.service
OutputId=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon
. . .
Se quiser exibir uma única propriedade, passe o sinalizador -p
com o nome da propriedade. Por exemplo, para ver os conflitos que a unidade sshd.service
possui, digite:
- systemctl show sshd.service -p Conflicts
OutputConflicts=shutdown.target
Vimos na seção de gerenciamento de serviços como parar ou desativar um serviço. No entanto, o systemd
também possui a capacidade de marcar uma unidade como absolutamente não iniciável, de modo automático ou manual, ligando-a ao /dev/null
. Isso é chamado de mascarar a unidade, e é possível com o comando mask
:
- sudo systemctl mask nginx.service
Isso irá impedir que o serviço Nginx seja iniciado, automaticamente ou manualmente, enquanto estiver mascarado.
Se verificar o list-unit-files
, verá que o serviço está agora listado como mascarado:
- systemctl list-unit-files
Output. . .
kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service static
nginx.service masked
quotaon.service static
rc-local.service static
rdisc.service disabled
rescue.service static
. . .
Se você tentar iniciar o serviço, verá uma mensagem como esta:
- sudo systemctl start nginx.service
OutputFailed to start nginx.service: Unit nginx.service is masked.
Para desmascarar uma unidade, tornando-a disponível para uso novamente, use o comando unmask
:
- sudo systemctl unmask nginx.service
Isso irá retornar a unidade ao seu estado anterior, permitindo que seja iniciada ou habilitada.
Embora o formato específico para arquivos de unidade esteja fora do âmbito deste tutorial, o systemctl
fornece mecanismos integrados para editar e modificar arquivos de unidade, se for necessário fazer ajustes. Essa funcionalidade foi adicionada na versão 218do systemd
.
O comando edit
, por padrão, irá abrir um trecho de código do arquivo de unidade para a unidade em questão:
- sudo systemctl edit nginx.service
Esse será um arquivo em branco que pode ser usado para substituir ou adicionar diretivas à definição da unidade. Um diretório será criado dentro do diretório /etc/systemd/system
, que contém o nome da unidade com o .d
anexado. Por exemplo, para o nginx.service
, um diretório chamado nginx.service.d
será criado.
Dentro deste diretório, um trecho de código chamado override.conf
será criado. Quando a unidade for carregada, o systemd
irá mesclar, na memória, o trecho sobrescrito com o arquivo de unidade completo. As diretivas do trecho terão precedência sobre aquelas encontradas no arquivo de unidade original.
Se quiser editar o arquivo de unidade completo ao invés de criar um fragmento, passe o sinalizador --full
:
- sudo systemctl edit --full nginx.service
Isso irá carregar o arquivo de unidade atual no editor, onde pode ser modificado. Quando o editor for fechado, o arquivo alterado será escrito em /etc/systemd/system
e terá precedência sobre a definição de unidade do sistema (geralmente encontrada em algum lugar em /lib/systemd/system
).
Para remover qualquer adição que tenha sido feita, exclua o diretório de configuração .d
da unidade ou o arquivo de serviço modificado de /etc/systemd/system
. Por exemplo, para remover um fragmento, podemos digitar:
- sudo rm -r /etc/systemd/system/nginx.service.d
Para remover um arquivo de unidade modificado completo, digitamos:
- sudo rm /etc/systemd/system/nginx.service
Depois de excluir o arquivo ou diretório, recarregue o processo do systemd
para que ele não tente mais fazer referência a esses arquivos e volte a usar as cópias do sistema. Faça isso digitando:
- sudo systemctl daemon-reload
Os alvos são arquivos de unidade especiais que descrevem um estado do sistema ou um ponto de sincronização. Assim como outras unidades, os arquivos que definem alvos podem ser identificados por seu sufixo, que neste caso é .target
. Os alvos não fazem muito por conta própria, mas são usados para agrupar outras unidades.
Isso pode ser usado para trazer o sistema para determinados estados, da mesma forma que outros sistemas init usam os níveis de execução. Eles são usados como referência para quando certas funções estão disponíveis, permitindo especificar o estado desejado em vez das unidades individuais necessárias para produzir esse estado.
Por exemplo, existe um swap.target
que é usado para indicar que o swap está pronto para ser usado. Unidades que fazem parte deste processo podem sincronizar-se com esse alvo indicando em sua configuração que elas são WantedBy=
ou RequiredBy=
pelo swap.target
. Unidades que exigem o swap para ficarem disponíveis podem especificar essa condição usando as especificações Wants=
, Requires=
e After=
para indicar a natureza do seu relacionamento.
O processo do systemd
possui um alvo padrão usado por ele ao inicializar o sistema. Satisfazer a cascata de dependências a partir desse único alvo irá trazer o sistema para o estado desejado. Para encontrar o alvo padrão para o seu sistema, digite:
- systemctl get-default
Outputmulti-user.target
Se quiser definir um alvo padrão diferente, use o set-default
. Por exemplo, se você possui um desktop gráfico instalado e quer que o sistema seja inicializado nele por padrão, altere seu alvo padrão de acordo:
- sudo systemctl set-default graphical.target
É possível obter uma lista dos alvos disponíveis em seu sistema digitando:
- systemctl list-unit-files --type=target
Ao contrário dos níveis de execução, vários alvos podem estar ativos ao mesmo tempo. Um alvo ativo indica que o systemd
tentou iniciar todas as unidades ligadas ao alvo e não tentou destruí-las novamente. Para ver todos os alvos ativos, digite:
- systemctl list-units --type=target
É possível iniciar todas as unidades associadas a um alvo e parar todas as unidades que não fazem parte da árvore de dependência. O comando que precisamos emitir para isso chama-se, apropriadamente, isolate
. Isso é parecido com alterar o nível de execução em outros sistemas init.
Por exemplo, se estiver operando em um ambiente gráfico com o graphical.target
ativo, você pode desligar o sistema gráfico e colocar o sistema em um estado de linha de comando multiusuário isolando o multi-user.target
. Como o graphical.target
depende do multi-user.target
, mas o contrário não é válido, todas as unidades gráficas serão interrompidas.
Pode ser interessante dar uma olhada nas dependências do alvo que você está isolando antes de executar este procedimento, de forma a garantir que não estará impedindo serviços vitais:
- systemctl list-dependencies multi-user.target
Quando estiver satisfeito com as unidades que serão mantidas vivas, isole o alvo digitando:
- sudo systemctl isolate multi-user.target
Existem alvos definidos para eventos importantes, como desligar ou reinicializar o sistema. No entanto, o systemctl
também possui alguns atalhos que adicionam outras funcionalidades adicionais.
Por exemplo, para colocar o sistema em modo de resgate (único usuário), simplesmente use o comando rescue
ao invés de isolate rescue.target
:
- sudo systemctl rescue
Isso irá fornecer a funcionalidade adicional de alertar todos os usuários conectados sobre o evento.
Para parar o sistema, use o comando halt
:
- sudo systemctl halt
Para iniciar um desligamento completo, use o comando poweroff
:
- sudo systemctl poweroff
Uma reinicialização pode ser feita com o comando reboot
:
- sudo systemctl reboot
Todos esses comandos alertam usuários conectados que o evento está ocorrendo, o que não acontece ao apenas executar ou isolar o alvo. Observe que a maioria das máquinas irão vincular os comandos mais curtos e convencionais para essas operações de modo que funcionem corretamente com o systemd
.
Por exemplo, para reiniciar o sistema, costuma-se digitar:
- sudo reboot
A partir agora, você deve estar familiarizado com algumas das capacidades básicas do comando systemctl
que permitem interagir e controlar sua instância do systemd
. O utilitário systemctl
será o seu ponto principal de interação para o gerenciamento do serviço e do estado do sistema.
Embora o systemctl
opere principalmente com o processo principal do systemd
, existem outros componentes do ecossistema do systemd
que são controlados por outros utilitários. Outras capacidades, como o gerenciamento de registro e sessões de usuário são controladas por daemons e utilitários de gerenciamento separados (journald
/journalctl
e logind
/loginctl
respectivamente). Gastar algum tempo para se familiarizar com essas outras ferramentas e daemons irá tornar o gerenciamento uma tarefa mais fácil.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.