Linux - Comandos Systemctl ou Systemd
Sempre crie uma frase de segurança única para jogos, Airdrops e qualquer outra coisa de origem desconhecida, em vez de usar sua carteira principal.
https://www.tecmint.com/list-all-running-services-under-systemd-in-linux/
Iniciando e interrompendo os 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:
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:
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:
Reiniciando e recarregando
Para reiniciar um serviço em execução, use o comando restart:
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:
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:
Habilitando e desabilitando serviços
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:
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:
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.
Verificando o status de serviços
Para verificar o status de um serviço em seu sistema, use o comando status:
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:
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:
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:
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.
Visão geral do estado do sistema
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.
Listando as unidades atuais
Para ver uma lista com todas as unidades ativas das quais o systemd sabe,
podemos usar o comando 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:
- UNIT: o nome da unidade de
systemd - LOAD: se a configuração da unidade foi analisada pelo
systemd. A configuração de unidades carregadas é mantida na memória. - ACTIVE: um estado resumido que diz se a unidade está ativa. Essa é geralmente uma maneira bastante simples de dizer se a unidade foi iniciada com sucesso ou não.
- SUB: esse é um estado de nível mais baixo que indica informações mais detalhadas sobre a unidade. Isso muitas vezes varia dependendo do tipo de unidade, estado e do método em si com o qual a unidade é executada.
- DESCRIPTION: uma breve descrição textual do que a unidade é/faz.
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:
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:
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:
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:
Listando todos os arquivos de unidade
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:
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.
Gerenciamento de unidades
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.
Exibindo um arquivo de unidade
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:
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).
Exibindo dependências
Para ver a árvore de dependências de uma unidade, use o comando list-dependencies:
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.
Verificando propriedades da unidade
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:
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:
OutputConflicts=shutdown.target
Mascarando e desmascarando unidades
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:
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:
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:
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:
Isso irá retornar a unidade ao seu estado anterior, permitindo que seja iniciada ou habilitada.
Editando arquivos de unidade
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:
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:
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:
Para remover um arquivo de unidade modificado completo, digitamos:
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:
Ajustando o estado do sistema (Runlevel) com alvos
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.
Obtendo e definindo o alvo padrão
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:
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:
Listando alvos disponíveis
É possível obter uma lista dos alvos disponíveis em seu sistema digitando:
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:
Isolando alvos
É 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:
Quando estiver satisfeito com as unidades que serão mantidas vivas, isole o alvo digitando:
Usando atalhos para eventos importantes
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:
Isso irá fornecer a funcionalidade adicional de alertar todos os usuários conectados sobre o evento.
Para
parar
o
sistema,
use
o
comando
halt:
Para
iniciar
um
desligamento
completo,
use
o
comando
poweroff:
Uma
reinicialização
pode
ser
feita
com
o
comando
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:
0 Comentários