No ecossistema Linux, poucas atualizações carregam o peso histórico e técnico da versão 259 do systemd. Lançada em dezembro de 2025, esta release é um “último aviso” que prepara o terreno para uma das mudanças mais significativas desde a adoção generalizada do init system moderno: a remoção completa do suporte a scripts legacy do System V (SysV).
A partir da versão 260, componentes fundamentais como o systemd-sysv-generator e o systemd-sysv-install serão removidos do código-fonte. Isso significa que qualquer serviço, ferramenta ou script personalizado que ainda dependa do formato tradicional /etc/init.d/ simplesmente deixará de funcionar nas próximas versões das distribuições que acompanharem este ciclo. Dessa forma, a migração para arquivos de unidade nativos do systemd (.service, .socket, etc.) torna-se obrigatória.
Este movimento agressivo em direção à modernização é acompanhado por outro anúncio impactante: o systemd 260 elevará significativamente suas dependências mínimas. Requererá um kernel Linux 5.10+, glibc 2.34+ e OpenSSL 3.0+, entre outros. Essas mudanças consolidam a base tecnológica do projeto, abandonando suporte a sistemas legados muito antigos e liberando os desenvolvedores para implementar features que dependem de APIs mais modernas do kernel.
Mudanças imediatas
Enquanto a remoção do SysV e a elevação dos requisitos estão no futuro, o systemd 259 traz uma série de mudanças imediatas que redefinem comportamentos padrão e fortalecem a segurança.
Uma das alterações mais perceptíveis para usuários finais e administradores é na gestão de logs. O journald, o subsistema de logging do systemd, agora assume por padrão o armazenamento persistente dos logs em /var/log/journal/. Anteriormente, o comportamento padrão era “automático”, dependendo da existência desse diretório. A nova postura garante que, por padrão, o histórico de logs não se perca entre reinicializações, oferecendo maior capacidade de auditoria e debug sem configuração adicional.
No front de segurança e gerenciamento de recursos, duas mudanças são técnicas, mas profundas:
- Os componentes de rede do systemd, systemd-networkd e systemd-nspawn, abandonaram totalmente o suporte ao legado iptables, migrando exclusivamente para o nftables. O nftables é o sucessor moderno do iptables no kernel Linux, oferecendo melhor desempenho, sintaxe mais limpa e capacidades avançadas;
- O sistema de cgroups versão 2 agora é montado com a contabilidade de Huge Pages (páginas de memória gigantes) ativada por padrão. Isso significa que o uso dessas páginas especiais de alto desempenho será contabilizado dentro dos limites de memória definidos para um contêiner ou serviço, permitindo um controle de recursos muito mais preciso e evitando que um processo consuma memória para além do limitador.
O endurecimento de segurança também atinge o processo de boot. O systemd-boot e o systemd-stub (usado em Unified Kernel Images – UKIs) removem o suporte ao TPM 1.2, mantendo apenas o TPM 2.0. Os desenvolvedores justificam que, em 2025, o nível de segurança do TPM 1.2 é questionável e seu suporte era incompleto. Essa é uma decisão que visa elevar a barreira de segurança para recursos como o Secure Boot e o sealing de chaves criptográficas.
Modularidade avançada
Um tema de grande impacto a longo prazo na versão 259, é a expansão massiva do suporte ao protocolo Varlink. O Varlink é um protocolo de IPC (para comunicação entre processos) mais simples e moderno que o D-Bus.
O gerenciador de serviços (PID1) agora expõe mais configurações de execução e novos métodos como Reload() e Reexecute() via Varlink, alcançando paridade com a interface D-Bus. Mais significativo ainda é que componentes críticos como systemd-repart (para particionamento), systemd-resolved (para DNS) e systemd-creds (para gerenciamento de credenciais) ganharam APIs Varlink novas ou expandidas. Essa evolução indica uma arquitetura mais modular, onde ferramentas externas podem interagir de forma mais limpa e eficiente com os subsistemas do systemd.
A busca por modularidade e redução de dependências rígidas é outra frente de trabalho. O systemd 259 dá um passo ousado ao não vincular mais a biblioteca libcap, reimplementando internamente a funcionalidade necessária. Além disso, passou a usar dlopen() para carregar dinamicamente (e opcionalmente) bibliotecas como PAM, libseccomp, libselinux e libmount. Isso resulta em árvores de dependência mais enxutas, especialmente benéficas para ambientes de contêineres, onde nem todas essas bibliotecas são necessárias ou desejadas.
Você está preparado para o futuro do systemd?
Fique por dentro das principais novidades da semana sobre tecnologia e Linux: receba nossa newsletter!