Controlar Serviços no Red Hat Enterprise Linux

Introdução

Neste laboratório, você ganhará experiência prática no gerenciamento de serviços do sistema no RHEL usando o comando systemctl. Você aprenderá a visualizar todos os serviços carregados e ativos, verificar o status de serviços específicos e controlar seu comportamento em tempo de execução iniciando, parando e reiniciando-os. Além disso, você explorará como recarregar configurações de serviço, habilitar ou desabilitar serviços para inicialização automática no boot e entenderá os conceitos avançados de mascaramento e desmascaramento de serviços para impedir sua ativação.

Este guia prático fornecerá as habilidades essenciais para a administração de sistemas, permitindo que você monitore e gerencie efetivamente o ciclo de vida de serviços cruciais para a operação do seu sistema RHEL.

Visualizar todos os serviços carregados e ativos com o systemctl

Nesta etapa, você aprenderá a identificar processos do sistema iniciados automaticamente usando o comando systemctl. O systemctl é a ferramenta principal para gerenciar serviços do systemd no Red Hat Enterprise Linux.

Primeiro, vamos explorar como listar todas as unidades de serviço carregadas e ativas no momento. O comando systemctl list-units --type=service é usado para esse fim. Este comando exibe unidades de serviço que o daemon systemd analisou e carregou com sucesso na memória, e que estão ativas no momento.

Abra seu terminal no ambiente RHEL. Você já está logado como usuário labex e seu diretório atual é ~/project.

Execute o seguinte comando para listar todas as unidades de serviço carregadas e ativas:

systemctl list-units --type=service

Você verá uma saída semelhante a esta, mostrando vários serviços e seus estados:

UNIT                  LOAD    ACTIVE  SUB      DESCRIPTION
atd.service           loaded  active  running  Job spooling tools
auditd.service        loaded  active  running  Security Auditing Service
chronyd.service       loaded  active  running  NTP client/server
crond.service         loaded  active  running  Command Scheduler
dbus-broker.service   loaded  active  running  D-Bus System Message Bus
...output omitted...

Vamos analisar as colunas na saída:

UNIT: Este é o nome da unidade de serviço, geralmente terminando em .service.
LOAD: Indica se o daemon systemd analisou com sucesso a configuração da unidade e a carregou na memória. loaded significa que foi bem-sucedido.
ACTIVE: Este é o estado de ativação de alto nível da unidade. active geralmente significa que a unidade foi iniciada com sucesso.
SUB: Este é o estado de ativação de baixo nível, fornecendo informações mais detalhadas. Para serviços em execução, running é comum.
DESCRIPTION: Uma breve descrição do que o serviço faz.

Pressione q para sair do comando.

Em seguida, você pode usar a opção --all com systemctl list-units --type=service para listar todas as unidades de serviço, independentemente de seus estados de ativação (ativo, inativo, falha, etc.). Isso pode ser útil para ver serviços que estão instalados, mas não estão em execução no momento.

Execute o seguinte comando:

systemctl list-units --type=service --all

A saída incluirá serviços que estão inactive ou em outros estados, fornecendo uma visão mais abrangente:

UNIT                          LOAD      ACTIVE   SUB     DESCRIPTION
  atd.service                 loaded    active   running Job spooling tools
  auditd.service              loaded    active   running Security Auditing ...
  auth-rpcgss-module.service  loaded    inactive dead    Kernel Module ...
  chronyd.service             loaded    active   running NTP client/server
  cpupower.service            loaded    inactive dead    Configure CPU power ...
  crond.service               loaded    active   running Command Scheduler
  dbus-broker.service         loaded    active   running  D-Bus System Message Bus
● display-manager.service     not-found inactive dead    display-manager.service
...output omitted...

Por fim, para ver o estado de todos os arquivos de unidade instalados, incluindo aqueles que não estão carregados ou ativos, você pode usar systemctl list-unit-files --type=service. Este comando mostra se um serviço está enabled (inicia no boot), disabled (não inicia no boot), static (não pode ser habilitado diretamente, mas pode ser iniciado por outra unidade) ou masked (impedido de iniciar).

Execute o seguinte comando:

systemctl list-unit-files --type=service

Você verá uma saída semelhante a esta, indicando o STATE e o VENDOR PRESET para cada arquivo de unidade de serviço:

UNIT FILE                         STATE       VENDOR PRESET
arp-ethers.service                disabled    disabled
atd.service                       enabled     enabled
auditd.service                    enabled     enabled
auth-rpcgss-module.service        static      -
autovt@.service                   alias       -
blk-availability.service          disabled    disabled
...output omitted...

Este comando é particularmente útil para entender quais serviços estão configurados para iniciar automaticamente quando o sistema é inicializado.

Verificar o status de um serviço específico com systemctl status

Nesta etapa, você aprenderá como verificar o status detalhado de um serviço específico usando o comando systemctl status. Este comando fornece informações abrangentes sobre um serviço, incluindo se ele está em execução, seu ID de processo (PID), uso de memória e entradas de log recentes.

Usaremos o crond.service (daemon cron) como exemplo. O daemon cron é um serviço comum que lida com tarefas agendadas.

Abra seu terminal no ambiente RHEL. Certifique-se de estar no diretório ~/project.

Execute o seguinte comando para verificar o status do crond.service:

systemctl status crond.service

Você verá uma saída detalhada semelhante a esta:

● crond.service - Command Scheduler
     Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; preset: enabled)
     Active: active (running) since Mon 2022-03-14 05:38:10 EDT; 25min ago
   Main PID: 1089 (crond)
      Tasks: 1 (limit: 35578)
     Memory: 1.2M
        CPU: 12ms
     CGroup: /system.slice/crond.service
             └─1089 /usr/sbin/crond -n

Mar 14 05:38:10 workstation systemd[1]: Started Command Scheduler.
Warning: some journal files were not opened due to insufficient permissions.

Vamos examinar os campos principais na saída:

Loaded: Esta linha informa se o arquivo de configuração da unidade de serviço foi processado. Também mostra o caminho para o arquivo da unidade (/usr/lib/systemd/system/crond.service) e seu status de habilitação (enabled significa que está configurado para iniciar no boot).
Active: Isso é crucial. Indica o estado atual do serviço. active (running) significa que o serviço está ativo no momento e seus processos estão em execução. Também mostra há quanto tempo está ativo. Outros estados podem ser inactive (não está em execução), active (exited) (concluiu uma tarefa única) ou failed (encontrou um erro).
Main PID: O ID do processo (PID) do processo principal associado ao serviço, juntamente com o nome do comando.
Tasks: O número de tarefas (threads) que o serviço está usando no momento.
Memory: A quantidade de memória que o serviço está consumindo.
CPU: O tempo de CPU consumido pelo serviço.
CGroup: Informações sobre o grupo de controle (control group) ao qual o serviço pertence, usado para gerenciamento de recursos.
As linhas abaixo de CGroup mostram entradas de log recentes relacionadas ao serviço, fornecendo insights sobre sua inicialização e atividades em curso.

Além do systemctl status, existem comandos mais simples para verificar rapidamente aspectos específicos do estado de um serviço:

Para verificar se um serviço está ativo:
```
systemctl is-active crond.service
```
Saída esperada:
```
active
```
Para verificar se um serviço está habilitado (configurado para iniciar no boot):
```
systemctl is-enabled crond.service
```
Saída esperada:
```
enabled
```
Para verificar se um serviço falhou:
```
systemctl is-failed crond.service
```
Saída esperada (se estiver executando corretamente):
```
active
```
Se um serviço tivesse problemas ao iniciar ou executar, este comando retornaria failed.

Esses comandos são úteis para scripts ou verificações rápidas quando você não precisa da saída detalhada do systemctl status.

Iniciar, parar e reiniciar um serviço com o systemctl

Nesta etapa, você aprenderá a gerenciar o ciclo de vida de serviços do sistema usando comandos systemctl. Você praticará iniciar, parar e reiniciar um serviço. Para este exercício, usaremos um serviço fictício que criaremos. Essa abordagem garante que possamos manipular um serviço com segurança sem afetar funções críticas do sistema.

Primeiro, vamos criar um arquivo de unidade de serviço simples. Este arquivo definirá um serviço que simplesmente grava um carimbo de data/hora em um arquivo de log a cada poucos segundos.

Crie um novo arquivo de unidade de serviço chamado mytest.service diretamente no diretório do sistema systemd usando o nano:

sudo nano /etc/systemd/system/mytest.service

Cole o seguinte conteúdo no editor nano:

[Unit]
Description=My Test Service
After=network.target

[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service is running." >> /tmp/mytest.log; sleep 5; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure

[Install]
WantedBy=multi-user.target

[Unit]: Contém informações genéricas sobre a unidade. Description fornece um nome legível por humanos, e After=network.target especifica que este serviço deve iniciar após a rede estar ativa.
[Service]: Define o comportamento do serviço.
- Type=simple: Indica um tipo de serviço simples onde o comando ExecStart é o processo principal.
- ExecStart: O comando a ser executado quando o serviço inicia. Aqui, é um loop bash que grava uma mensagem com carimbo de data/hora em /tmp/mytest.log a cada 5 segundos.
- ExecStop: O comando a ser executado quando o serviço para. Ele grava uma mensagem de parada no log.
- Restart=on-failure: Configura o serviço para reiniciar se ele sair com um status diferente de zero.
[Install]: Contém informações sobre como o serviço deve ser instalado. WantedBy=multi-user.target significa que este serviço deve ser iniciado quando o sistema atingir o nível de execução multiusuário.

Salve o arquivo pressionando Ctrl+X, depois Y para confirmar e Enter para salvar.

Agora, recarregue o daemon systemd para reconhecer o novo arquivo de serviço:

sudo systemctl daemon-reload

Iniciar um serviço

Para iniciar um serviço, use o comando systemctl start.

Execute o seguinte comando para iniciar o mytest.service. Observe que precisamos usar sudo porque as operações do systemctl geralmente exigem privilégios de root.

sudo systemctl start mytest.service

Não haverá saída imediata se o comando for bem-sucedido.

Agora, verifique se o serviço está em execução verificando seu status:

systemctl status mytest.service

Você deve ver uma saída indicando que o serviço está active (running):

● mytest.service - My Test Service
     Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
     Active: active (running) since ...
   Main PID: ... (bash)
      Tasks: 2 (limit: ...)
     Memory: ...
        CPU: ...
     CGroup: /system.slice/mytest.service
             ├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
             └─... sleep 5

...output omitted...

Você também pode verificar o arquivo de log para ver se o serviço está gravando mensagens:

tail -f /tmp/mytest.log

Você deve ver novas linhas aparecendo a cada 5 segundos, semelhante a isto:

Tue Jul 22 09:15:09 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:14 AM CST 2025: My Test Service is running.

Pressione Ctrl+C para sair do tail.

Parar um serviço

Para parar um serviço em execução, use o comando systemctl stop.

Execute o seguinte comando para parar o mytest.service:

sudo systemctl stop mytest.service

Novamente, não haverá saída imediata.

Verifique se o serviço parou:

systemctl status mytest.service

A saída agora deve mostrar Active: inactive (dead):

○ mytest.service - My Test Service
     Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
     Active: inactive (dead) since ...
...output omitted...

Verifique o arquivo de log /tmp/mytest.log novamente. Você deve ver a mensagem "My Test Service stopped." e nenhuma nova mensagem "running".

tail /tmp/mytest.log

A saída será semelhante a esta:

Tue Jul 22 09:15:24 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.

Reiniciar um serviço

Para reiniciar um serviço, use o comando systemctl restart. Este comando primeiro para o serviço e depois o inicia novamente. Isso é útil quando você fez alterações na configuração de um serviço e precisa que elas entrem em vigor.

Execute o seguinte comando para reiniciar o mytest.service:

sudo systemctl restart mytest.service

Verifique se o serviço está em execução novamente:

systemctl status mytest.service

Você deve ver Active: active (running) novamente, e o Main PID provavelmente será um novo número, indicando que um novo processo foi iniciado.

● mytest.service - My Test Service
     Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
     Active: active (running) since ...
   Main PID: ... (bash)
      Tasks: 2 (limit: ...)
     Memory: ...
        CPU: ...
     CGroup: /system.slice/mytest.service
             ├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
             └─... sleep 5
...output omitted...

Verifique o arquivo de log /tmp/mytest.log para confirmar que o serviço retomou a gravação de mensagens "running".

tail -f /tmp/mytest.log

Você deve ver uma mensagem "stopped" seguida por novas mensagens "running":

Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.
Tue Jul 22 09:15:40 AM CST 2025: My Test Service is running.

Pressione Ctrl+C para sair do tail.

Aplicar alterações de configuração a um serviço

Nesta etapa, você aprenderá sobre como recarregar configurações de serviço. Alguns serviços podem aplicar alterações aos seus arquivos de configuração sem precisar de uma reinicialização completa. Isso é conhecido como "recarregar" (reload) o serviço. Recarregar é geralmente preferível a reiniciar porque evita o tempo de inatividade do serviço e preserva conexões ou estados existentes. Quando um serviço é recarregado, seu ID de processo (PID) geralmente permanece o mesmo, ao contrário de uma reinicialização completa, onde o PID muda.

Continuaremos usando nosso mytest.service da etapa anterior. Modificaremos seu comportamento e tentaremos recarregá-lo para ver o que acontece.

Primeiro, certifique-se de que o mytest.service esteja em execução. Se não estiver, inicie-o:

sudo systemctl start mytest.service

Verifique seu status e anote seu Main PID:

systemctl status mytest.service

Agora, vamos modificar o arquivo mytest.service para alterar a mensagem que ele registra e o intervalo. Alteraremos a mensagem de log e a duração do sleep.

Abra /etc/systemd/system/mytest.service com o nano:

sudo nano /etc/systemd/system/mytest.service

Altere a linha ExecStart para o seguinte, modificando a mensagem e o tempo de sleep de 5 para 2 segundos:

[Unit]
Description=My Test Service
After=network.target

[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service (reloaded) is running." >> /tmp/mytest.log; sleep 2; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure

[Install]
WantedBy=multi-user.target

Salve o arquivo pressionando Ctrl+X, depois Y e Enter.

Após salvar as alterações, você precisa informar ao systemd que a configuração do serviço mudou.

sudo systemctl daemon-reload

Agora, vamos tentar recarregar o serviço para aplicar as alterações:

sudo systemctl reload mytest.service

Você provavelmente encontrará um erro:

Failed to reload mytest.service: Job type reload is not applicable for unit mytest.service.

Este erro ocorre porque nosso serviço simples não está configurado para lidar com uma solicitação de recarregamento. Para que um serviço seja recarregável, seu arquivo de unidade deve incluir uma diretiva ExecReload, que especifica o comando a ser executado para recarregar a configuração. Como nosso mytest.service não possui isso, o systemd não sabe como recarregá-lo.

Em situações como esta, o systemd fornece um comando conveniente: reload-or-restart. Este comando tentará recarregar o serviço, mas se o recarregamento não for suportado, ele recorrerá à reinicialização do serviço. Esta é frequentemente uma maneira mais segura e eficaz de aplicar alterações de configuração.

Vamos usar reload-or-restart agora:

sudo systemctl reload-or-restart mytest.service

Este comando deve ter sucesso. Agora, verifique o status do serviço novamente:

systemctl status mytest.service

Observe o Main PID. Como nosso serviço foi reiniciado (porque não pôde ser recarregado), você notará que o Main PID é um novo número. Isso confirma que o processo antigo foi parado e um novo foi iniciado com a configuração atualizada.

Por fim, vamos verificar o arquivo /tmp/mytest.log para ver se as alterações entraram em vigor.

tail -f /tmp/mytest.log

Você deve ver a nova mensagem de log "My Test Service (reloaded) is running." aparecendo a cada 2 segundos. Pressione Ctrl+C para sair do tail.

Habilitar e desabilitar serviços no boot com o systemctl

Nesta etapa, você aprenderá como configurar serviços para iniciar automaticamente no momento da inicialização (habilitar) ou impedir que iniciem no boot (desabilitar). Isso é crucial para gerenciar recursos do sistema e garantir que os serviços necessários estejam disponíveis quando o sistema iniciar.

Em um ambiente systemd típico, habilitar um serviço cria links simbólicos nos diretórios de configuração apropriados do systemd (por exemplo, /etc/systemd/system/multi-user.target.wants/) que apontam para o arquivo de unidade do serviço. Desabilitar um serviço remove esses links.

Como estamos em um ambiente conteinerizado onde o systemd pode não estar totalmente operacional no sentido tradicional, os comandos enable e disable podem não criar links simbólicos reais no diretório /etc/systemd/system que persistam após reinicializações do contêiner. No entanto, o systemctl ainda processa esses comandos e atualiza seu estado interno, que é o que observaremos.

Continuaremos usando nosso mytest.service para esta demonstração.

Primeiro, certifique-se de que o mytest.service esteja parado da etapa anterior:

sudo systemctl stop mytest.service

Habilitar um serviço

Para habilitar um serviço, use o comando systemctl enable. Este comando configura o serviço para iniciar automaticamente quando o sistema inicializa.

Execute o seguinte comando para habilitar o mytest.service:

sudo systemctl enable mytest.service

Você pode ver uma saída semelhante a esta, indicando que um link simbólico seria criado em um ambiente systemd completo:

Created symlink /etc/systemd/system/multi-user.target.wants/mytest.service → /etc/systemd/system/mytest.service.

Agora, verifique se o serviço está habilitado usando systemctl is-enabled:

systemctl is-enabled mytest.service

Saída esperada:

enabled

Isso confirma que o systemctl agora considera o mytest.service como habilitado para o boot.

Você também pode combinar a habilitação e a inicialização de um serviço em um único comando usando a opção --now. Esta é uma maneira conveniente de garantir que um serviço esteja em execução imediatamente e configurado para iniciar em futuras inicializações.

Primeiro, vamos desabilitá-lo para preparar para a demonstração do --now:

sudo systemctl disable mytest.service

Agora, habilite e inicie-o simultaneamente:

sudo systemctl enable --now mytest.service

Verifique seu status e habilitação:

systemctl status mytest.service
systemctl is-enabled mytest.service

Você deve ver Active: active (running) no comando status e enabled no comando is-enabled.

Desabilitar um serviço

Para desabilitar um serviço, use o comando systemctl disable. Este comando remove a configuração que faz com que o serviço inicie no momento da inicialização.

Execute o seguinte comando para desabilitar o mytest.service:

sudo systemctl disable mytest.service

Você pode ver uma saída indicando a remoção do link simbólico:

Removed /etc/systemd/system/multi-user.target.wants/mytest.service.

Agora, verifique se o serviço está desabilitado:

systemctl is-enabled mytest.service

Saída esperada:

disabled

Semelhante à habilitação, você pode combinar a desabilitação e a parada de um serviço usando a opção --now. Isso parará o serviço imediatamente e impedirá que ele inicie em futuras inicializações.

sudo systemctl disable --now mytest.service

Verifique seu status e habilitação:

systemctl status mytest.service
systemctl is-enabled mytest.service

Você deve ver Active: inactive (dead) no comando status e disabled no comando is-enabled.

Isso conclui a demonstração de habilitação e desabilitação de serviços. Lembre-se de que, em um ambiente systemd real, esses comandos manipulam diretamente a configuração de inicialização.

Mascarar e desmascarar serviços com o systemctl

Nesta etapa final, você aprenderá sobre mascarar (mask) e desmascarar (unmask) serviços. Mascarar um serviço é uma maneira poderosa de impedir que ele seja iniciado, seja manualmente ou automaticamente no boot.

Quando você mascara um serviço, o systemd cria um link simbólico de /etc/systemd/system/<service-name>.service para /dev/null, tornando efetivamente o arquivo de unidade de serviço indisponível para o systemd. Esta é uma alternativa mais forte ao disable.

Este mecanismo funciona melhor para serviços definidos em /usr/lib/systemd/system, que é onde os pacotes instalam seus arquivos de serviço. O comando mask cria um arquivo "vazio" de substituição em /etc/systemd/system. No entanto, como você descobriu, se você tentar mascarar um serviço que criou diretamente em /etc/systemd/system (como nosso mytest.service), o comando pode falhar porque foi projetado para não sobrescrever um arquivo de configuração existente, o que causaria perda de dados.

Para demonstrar o mascaramento corretamente, usaremos um serviço pré-existente, o atd.service.

Primeiro, vamos verificar o status atual do atd.service. Ele deve estar ativo e habilitado.

systemctl status atd.service

A saída será semelhante a esta, mostrando que o serviço está ativo e em execução:

● atd.service - Deferred execution scheduler
     Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-07-22 09:13:06 CST; 22min ago
       Docs: man:atd(8)
   Main PID: 1222 (atd)
      Tasks: 1 (limit: 22509)
     Memory: 900.0K
        CPU: 5ms
     CGroup: /system.slice/atd.service
             └─1222 /usr/sbin/atd -f

Mascarar um serviço

É uma boa prática parar um serviço antes de mascará-lo.

sudo systemctl stop atd.service

Agora, execute o seguinte comando para mascarar o atd.service:

sudo systemctl mask atd.service

Você verá uma saída indicando a criação de um link simbólico para /dev/null:

Created symlink /etc/systemd/system/atd.service → /dev/null.

Agora, tente iniciar o serviço mascarado:

sudo systemctl start atd.service

Você receberá uma mensagem de erro, indicando que o serviço está mascarado:

Failed to start atd.service: Unit atd.service is masked.

Você também pode verificar o estado do serviço usando systemctl list-unit-files:

systemctl list-unit-files --type=service | grep atd.service | tee ~/project/atd-mask-state.txt

A saída deve mostrar masked para o atd.service:

atd.service                            masked      enabled

Isso confirma que o serviço agora está mascarado e não pode ser iniciado.

Desmascarar um serviço

Para desmascarar um serviço, use o comando systemctl unmask. Este comando remove o link simbólico para /dev/null, restaurando o arquivo de serviço original de /usr/lib/systemd/system.

Execute o seguinte comando para desmascarar o atd.service:

sudo systemctl unmask atd.service

Você verá uma saída indicando a remoção do link simbólico:

Removed "/etc/systemd/system/atd.service".

Após desmascarar, inicie o serviço novamente, pois o unmask apenas remove o link /dev/null e não reinicia o serviço para você.

sudo systemctl start atd.service

Agora, verifique o estado do serviço:

systemctl status atd.service

Você deve ver Active: active (running), semelhante a isto:

● atd.service - Deferred execution scheduler
     Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-07-22 09:36:10 CST; 2s ago
       Docs: man:atd(8)
   Main PID: 7372 (atd)
      Tasks: 1 (limit: 22509)
     Memory: 868.0K
        CPU: 6ms
     CGroup: /system.slice/atd.service
             └─7372 /usr/sbin/atd -f

Isso conclui o laboratório sobre controle de serviços e daemons. Você aprendeu como visualizar, iniciar, parar, reiniciar, recarregar, habilitar, desabilitar, mascarar e desmascarar serviços usando o systemctl.

Resumo

Neste laboratório, ganhamos experiência prática no gerenciamento de serviços do sistema usando o comando systemctl, mesmo dentro de um ambiente conteinerizado onde o systemd pode não ser o sistema de inicialização principal. Aprendemos como listar todas as unidades de serviço carregadas e ativas usando systemctl list-units --type=service, entendendo as colunas UNIT, LOAD, ACTIVE e SUB para interpretar os estados dos serviços.

Além disso, exploramos operações essenciais de gerenciamento de serviços: verificar o status de um serviço específico com systemctl status e controlar o ciclo de vida do serviço iniciando, parando e reiniciando serviços. Também abordamos como recarregar configurações de serviço, habilitar e desabilitar serviços para controlar seu comportamento no momento da inicialização e os conceitos avançados de mascaramento e desmascaramento de serviços para impedir que sejam iniciados. Este conjunto abrangente de habilidades fornece uma base sólida para o gerenciamento de serviços em sistemas RHEL.