03 - Comandos (service, chkconfig, update-rc.d)

A arquitetura do SysVinit, baseada puramente na invocação de scripts em /etc/init.d/ e no sequenciamento lexicográfico de links simbólicos em /etc/rcX.d/, expunha o administrador do sistema a uma superfície de gerenciamento excessivamente frágil. A manipulação direta desses artefatos estruturais induzia a dois vetores críticos de falha: a contaminação do ambiente de execução e a quebra assíncrona da ordem de dependências durante a criação manual de links.

Para abstrair a complexidade destas operações e blindar o sistema contra o erro humano, os ecossistemas Linux desenvolveram ferramentas de alto nível que atuam como a Interface de Programação de Aplicações (API) do administrador para a máquina de estados do SysVinit. As três ferramentas fundamentais que pavimentaram esta abstração são o utilitário invocador service, e os orquestradores de estado estático chkconfig (família Red Hat) e update-rc.d (família Debian).

1. O Utilitário service: Invocação e Sanitização de Ambiente

Embora um administrador possa tecnicamente iniciar o servidor web digitando /etc/init.d/apache2 start diretamente no prompt do terminal, essa prática é considerada uma falha arquitetural severa sob o prisma do SysVinit.

O problema reside no mecanismo de herança de processos do UNIX. Ao executar o script diretamente, o interpretador herda integralmente o espaço de variáveis de ambiente (Environment Variables) da sessão interativa do administrador. Variáveis como $PATH, $LD_LIBRARY_PATH, $USER, $LANG e aliases customizados são injetados na rotina de inicialização do daemon. Isso cria um cenário de não-determinismo: um serviço pode funcionar perfeitamente quando iniciado manualmente pelo usuário root, mas falhar miseravelmente durante o boot real, onde essas variáveis interativas não existem.

A Mecânica de Sanitização

O comando service foi concebido exclusivamente para garantir o determinismo através da sanitização estrita do ambiente. Estruturalmente, ele é um script bash enxuto que realiza a seguinte sequência de instruções:

1. Limpeza do Espaço de Variáveis: O service invoca o comando env -i para descartar absolutamente todas as variáveis do shell atual.
2. Reconstrução de Variáveis Essenciais: Ele injeta manualmente um subconjunto minimalista e seguro de variáveis: define o $PATH estrito para /sbin:/usr/sbin:/bin:/usr/bin e preserva apenas as variáveis $TERM (para garantir que funções de formatação de cor no console não quebrem) e $LANG=C (para forçar a codificação POSIX ASCII em logs).
3. Alteração de Contexto de Diretório: Executa um cd / para garantir que o daemon não prenda a montagem de um diretório arbitrário de onde o administrador executou o comando.
4. Invocação Mapeada: Finalmente, ele mapeia a sintaxe service <nome> <ação> para a execução canônica e estéril /etc/init.d/<nome> <ação>.

Em sistemas modernos, o comando service atua primariamente como uma camada de retrocompatibilidade (um shim). Se ele detectar que a máquina utiliza o systemd como PID 1 (verificando se /run/systemd/system existe), ele silencia a chamada tradicional e redireciona a requisição via IPC para systemctl <ação> <nome>.service, mantendo a fluidez operacional para scripts legados.

2. O Orquestrador chkconfig (Ecossistema Red Hat / Suse)

No ecossistema derivado do SVR4 e popularizado pela Red Hat, o utilitário chkconfig foi a solução arquitetural para o gerenciamento de links simbólicos nos diretórios de runlevels. O objetivo primário do chkconfig é desobrigar o administrador de saber que o serviço SSH deve ser o S55sshd no Runlevel 3 e K25sshd no Runlevel 0.

A Assinatura de Metadados (# chkconfig:)

Para que o utilitário saiba como posicionar o script, todo arquivo contido em /etc/init.d/ compatível com o chkconfig deve possuir uma string mágica em seu cabeçalho, mascarada como um comentário bash.

A sintaxe canônica é:
# chkconfig: <runlevels_padrao> <prioridade_start> <prioridade_kill>

Exemplo para um servidor web:
# chkconfig: 2345 85 15

Esta assinatura imperativa instrui a ferramenta do seguinte modo:

• Se o administrador executar chkconfig httpd on, o utilitário entrará nos diretórios /etc/rc2.d/, rc3.d/, rc4.d/ e rc5.d/, deletará qualquer link antigo associado ao httpd, e criará o link estrito S85httpd apontando para ../init.d/httpd.
• Para todos os runlevels não listados na assinatura (neste caso, 0, 1 e 6), a ferramenta garantirá a existência do link K15httpd, assegurando que o serviço seja sumariamente encerrado ao transitar para o modo de desligamento ou manutenção.

Matriz de Estados e Multiplexação xinetd

Ao executar chkconfig --list, o utilitário lê o estado atual do sistema de arquivos e desenha uma matriz de estado. Ele não lê um banco de dados opaco; ele escaneia em tempo real as pastas rcX.d e traduz a existência de prefixos S ou K em on ou off para cada um dos sete runlevels.

Adicionalmente, o chkconfig expandiu seu escopo para atuar como gestor do super-servidor xinetd (o daemon que escuta portas e ativa outros serviços dinamicamente). Ele manipula diretamente os arquivos de texto em /etc/xinetd.d/, alterando a flag booleana disable = yes para disable = no, consolidando a gerência de serviços contínuos (daemons) e serviços transientes (sockets) sob uma única CLI.

3. O Orquestrador update-rc.d e insserv (Ecossistema Debian/Ubuntu)

Em contraponto ao modelo imperativo do chkconfig, o ecossistema Debian desenvolveu o update-rc.d. Em sua encarnação original, o update-rc.d não dependia de cabeçalhos internos, mas exigia que o administrador passasse as ordens lexicográficas via argumento no prompt.

Comando clássico herdado:
update-rc.d apache2 defaults 20 80
(O que forçaria o link de inicialização na prioridade 20 e terminação na 80 para os runlevels padrões ditados pelo empacotador Debian).

A Evolução Topológica: LSB e Dependency-Based Boot

À medida que as interdependências entre serviços tornaram-se bizantinas (ex: o Apache não pode subir antes do MySQL, que não pode subir antes da rede, que depende do LVM), o ecossistema Debian integrou o backend insserv ao update-rc.d, migrando de uma lógica de prioridade estática para uma lógica dinâmica de Grafos de Dependência (Dependency-Based Boot).

Nesta arquitetura moderna, o update-rc.d ignora os números passados manualmente via CLI. Em vez disso, ele invoca o utilitário insserv, que processa rigorosamente o bloco LSB Core (### BEGIN INIT INFO) presente no topo do script alvo.
Ao detectar o comando update-rc.d <nome> enable, o motor de compilação topológica realiza as seguintes ações no plano de fundo:

1. Ele mapeia os metadados de Required-Start e Should-Start.
2. Executa um algoritmo de ordenação topológica (Topological Sort) em todo o ecossistema de scripts em /etc/init.d/.
3. Renomeia massivamente todos os links simbólicos do sistema em tempo real, atribuindo números novos de forma a garantir que a sequência temporal respeite matematicamente a árvore de dependência recém-alterada.

A Mecânica de Preservação de Estado (Desabilitação Suave)

Uma complexidade arquitetural única do update-rc.d reside no tratamento do verbo disable.
Em outros sistemas, desabilitar um serviço implica em simplesmente deletar o link S. No Debian, se o link for deletado, a próxima atualização do pacote via apt-get upgrade notará a ausência do link, presumirá que a instalação falhou e o recriará agressivamente, reativando um serviço que o administrador queria silenciar.

Para resolver este conflito de gerência de configuração, a instrução update-rc.d <nome> disable utiliza a técnica de Renomeação Semântica: ele altera o link de inicialização S (Start) para K (Kill) dentro dos runlevels ativos. Assim, o gerenciador de pacotes do SO detecta que o serviço está configurado no sistema de arquivos, e respeita o estado do administrador de mantê-lo adormecido durante o próximo ciclo de boot.