Tema: systemd
-
cgroups v2 no host: verificar o modo e ler os limites de recursos por unidade
Os runtimes de contêineres modernos e o systemd usam cgroups v2 (a hierarquia unificada) para impor limites de memória e CPU. Esta metodologia mostra como confirmar que o host está em modo unificado, navegar pela árvore com systemd-cgls/systemd-cgtop e ler os limites reais de uma unidade ou de um contêiner.
-
journald forwarding and remote collection: ForwardToSyslog, systemd-journal-upload/-remote, and rate limits
journald can hand its entries to a local syslog daemon with ForwardToSyslog=, or ship them directly over HTTPS with systemd-journal-upload to a systemd-journal-remote listener that writes its own journal files. Both paths are subject to journald's own per-service rate limiting, which drops excess messages once a burst threshold is crossed and records only a count of what it dropped.
-
Timers do systemd como substituto do cron: OnCalendar, Persistent= e RandomizedDelaySec
Uma unidade .timer do systemd combinada com um .service do tipo oneshot pode substituir uma entrada do crontab e ainda executa tarefas perdidas após períodos de inatividade e distribui a carga com atrasos aleatórios em vários hosts. Esta metodologia cria, valida e ativa esse par de unidades e explica o que Persistent= e RandomizedDelaySec= realmente fazem.
-
"Too many open files" (EMFILE) e o limite de descritores de arquivo
EMFILE, exibido como "Too many open files", indica que um processo atingiu o próprio limite de descritores de arquivo abertos ao mesmo tempo, documentado como RLIMIT_NOFILE. O artigo mostra como distinguir um vazamento real de descritores de um limite simplesmente baixo demais e como aumentá-lo no shell, no PAM e em units do systemd.
-
Dialetos de parsing de arquivos .env: aspas, export, valores multilinha e expansão em cinco carregadores
Docker Compose, docker run --env-file, python-dotenv, o dotenv do Node, o EnvironmentFile= do systemd e o source do arquivo em um shell aceitam arquivos de aparência parecida, mas divergem quanto a aspas, à palavra-chave export, a valores multilinha e à expansão de ${VAR}.
-
Executar contêineres Podman como serviços systemd com Quadlet
O Quadlet permite que o systemd gerencie contêineres Podman diretamente a partir de arquivos de unidade .container declarativos, substituindo o fluxo obsoleto do podman generate systemd. Esta metodologia cobre os locais dos arquivos para serviços de sistema e de usuário, a ativação e o rótulo de atualização automática.
-
A cadeia de boot do Linux para diagnóstico: firmware, bootloader, kernel, initramfs e systemd
O boot do Linux passa pelo firmware, por um bootloader, pelo kernel, por um initramfs e, por fim, pelo gerenciador do sistema, e cada etapa entrega o controle à seguinte. Saber o que cada uma faz e onde registra logs permite restringir uma falha de boot a uma única etapa antes de alterar qualquer coisa.
-
Tarefas agendadas comparadas: cron, systemd timers, launchd, Task Scheduler e cron/at do AIX
Cada agendador responde de forma diferente a uma pergunta: o que acontece com uma tarefa cujo horário passou enquanto a máquina estava desligada ou em suspensão? A comparação entre cron, systemd timers, as chaves de calendário do launchd e o Task Scheduler do Windows mostra que só o launchd recupera a execução após a suspensão por padrão; os demais só o fazem se forem configurados para isso.
-
systemd rescue.target e emergency.target: como entrar neles e voltar ao funcionamento normal
O rescue.target inicia o sistema base e um shell de usuário único; o emergency.target pula quase tudo e abre um shell no console, com o sistema de arquivos raiz possivelmente ainda somente leitura. Ambos são acessados com o parâmetro de kernel systemd.unit= e exigem um retorno deliberado ao default.target depois.
-
Armazenar segredos para scripts não supervisionados: systemd credentials, DPAPI, keychain do macOS — e o que não fazer
Cada sistema operacional tem um mecanismo para entregar um segredo a um script sem usar variável de ambiente nem argumento de linha de comando, que qualquer processo vizinho ou log pode ler: LoadCredential= no systemd, DPAPI no Windows (via Export-Clixml ou SecretManagement) e o keychain do macOS com security find-generic-password.
-
Gerenciadores de serviços comparados: systemd, launchd, Service Control Manager, SRC e rc.d/OpenRC
Todo sistema operacional de uso geral tem algo que inicia, para e supervisiona serviços e os executa no boot, mas os comandos e o modelo de persistência variam. Esta referência compara iniciar, parar, consultar o estado, habilitar no boot e acessar logs em systemd, launchd, Service Control Manager do Windows, SRC do AIX, rc.d do FreeBSD e OpenRC do Alpine.
-
Consultar o journal do systemd com journalctl: unidade, boot, prioridade, intervalo de tempo e saída JSON
O journalctl filtra o journal do systemd por unidade, boot, prioridade e intervalo de tempo e gera saída legível por máquina, mas só se o journal estiver configurado para persistir entre reinicializações. Esta metodologia cobre consultas precisas, armazenamento persistente e os limites de tamanho em journald.conf.
-
Como identificar um host Linux desconhecido antes de alterar qualquer coisa nele
Antes de mudar a configuração de uma máquina Linux que não montou, um agente ou operador deve apurar a distribuição, o kernel, o estado de virtualização ou contêiner, o sistema init, o gerenciador de pacotes e o estado do controle de acesso obrigatório, cada um com um comando simples e não destrutivo.
-
Como editar o /etc/fstab com segurança: UUIDs, nofail, opções x-systemd e findmnt --verify
Uma linha incorreta no /etc/fstab pode deixar o sistema num shell de emergência no próximo boot. Esta metodologia usa UUID= em vez de nomes de dispositivo, nofail e x-systemd.device-timeout= para montagens opcionais, e findmnt --verify com mount -a para testar o arquivo antes de reiniciar.
-
Códigos de saída do systemctl: is-active, is-enabled, is-failed e o que significa o código LSB 3
Os subcomandos is-active, is-enabled e is-failed do systemctl documentam um contrato simples de 0 contra não zero (na prática com valores no estilo LSB, como 3 para inativo e 4 para unit desconhecida), enquanto systemctl status segue a antiga convenção dos scripts init LSB, em que 3 significa «não está em execução» e não um erro de execução. Ler 3 ou 4 como uma chamada com defeito é a principal forma de agentes interpretarem mal o systemctl.
-
Strings de duração e intervalo: ISO 8601, ParseDuration do Go, systemd, Prometheus, PostgreSQL e TimeSpan do .NET
PT1H30M, 1h30m, '1h 30min' e 01:30:00 podem descrever o mesmo intervalo de tempo, mas cada parser aceita um conjunto diferente de sufixos de unidade e rejeita o resto; por isso, uma string de duração copiada de um sistema para outro muitas vezes simplesmente falha ao ser interpretada.
-
Interpretar a pressão de memória no Linux: free, swap, o OOM killer e OOMScoreAdjust
A coluna «available» do comando free, e não «free», indica a folga real de memória, e um processo morto sob pressão de memória deixa registo no log do kernel ou no journal, em vez de simplesmente desaparecer. Este artigo explica o que ler e como influenciar a escolha do processo pelo OOM killer.
-
Diagnóstico de resolução de nomes em um host com systemd: resolvectl, resolv.conf, nsswitch e getent versus dig
Em um host com systemd-resolved, o /etc/resolv.conf geralmente só aponta para um stub listener local, os servidores DNS reais de cada link ficam no resolvectl, e o /etc/nsswitch.conf decide se o getent hosts chega a consultar o DNS. Confundir essas camadas explica a maioria dos relatos de "o dig funciona, mas a aplicação não".
-
Configurar parâmetros do kernel Linux com sysctl: alterações em tempo de execução versus /etc/sysctl.d
O comando sysctl -w altera um parâmetro do kernel apenas até a próxima reinicialização; para torná-lo persistente, é preciso colocar um arquivo em /etc/sysctl.d/ e entender a ordem de carregamento entre /usr/lib, /etc e /run. O sysctl --system aplica todos os arquivos configurados e mostra qual deles prevalece em caso de conflito.
Legível por máquina: JSON