Systemd v258 é lançado e remove de vez o suporte ao cgroup v1 e aos “runlevels” do System V

Escrito por
Emanuel Negromonte
Emanuel Negromonte é Jornalista, Mestre em Tecnologia da Informação e atualmente cursa a segunda graduação em Engenharia de Software. Com 14 anos de experiência escrevendo sobre...

Você percebeu o barulho? systemd v258 chegou com espírito de faxina geral. É uma daquelas versões que mudam o “piso” do ecossistema: adeus cgroup v1, adeus controle de estado ao estilo System V (os velhos runlevels), e um novo requisito mínimo de base — Kernel 5.4. A partir de agora, a hierarquia cgroup v2 é sempre montada no boot, consolidando uma migração que já dura anos e simplificando o gerenciamento de recursos em Linux moderno. O resultado prático? Menos ambiguidade entre “legacy”, “hybrid” e “unified”, políticas mais previsíveis e uma superfície de problemas reduzida.

O fim de uma era: mudanças incompatíveis e remoções de legado

A manchete é direta: cgroup v1 saiu de cena. Se algum serviço seu ainda pressupõe a hierarquia antiga, é hora de revisar unidades, ferramentas e métricas para o cgroup v2. A vantagem não é só estética: com uma única árvore de controle, o planejamento de CPU/memória/I/O fica menos sujeito a inconsistências, e a vida dentro de containers e slices ganha coerência de verdade.

Outra remoção simbólica: o modelo System V deixa de ditar o estado do sistema. Foram removidos /dev/initctl, os comandos initctl, runlevel e telinit, além das unidades runlevel[0-6].target. Em termos práticos: lembra do clássico “telinit 3 para cair no modo texto”? Esqueça. O systemd já havia substituído esse paradigma há anos; o v258 apenas encerra o ciclo, deixando targets e unidades como o caminho oficial — mais expressivo, auditável e componível.

A base de kernel também sobe. A versão mínima exigida agora é Kernel 5.4 (com recomendações superiores). Isso reduz o número de condicionais e “gambiarras” internas para suportar sistemas muito antigos e libera o projeto para assumir funcionalidades consolidadas do kernel recente. Se você mantém uma frota heterogênea, vale planejar a atualização de kernels antes de adotar o v258 em produção.

Segurança aprimorada por padrão

A versão traz ajustes aparentemente pequenos que têm impacto real no dia a dia:

  • TTYs/PTS com 0600 por padrão: antes era 0620. Na prática, “mesg n” vira o padrão — outros usuários não podem escrever no seu terminal por padrão. É uma mudança que fecha uma porta histórica para incômodos e abusos. Se você depende explicitamente do comportamento antigo, a reversão existe no build (-Dtty-mode=0620), mas a recomendação é abraçar o novo default.
  • Regras do udev mais rígidas: systemd-udevd agora ignora OWNER=/GROUP= quando apontam para usuários/grupos não-sistema. Isso evita que nós de dispositivo apareçam pertencendo a contas comuns. Além disso, as ACLs vinculadas ao tag uaccess passam a ser gerenciadas de forma consistente pelo udev (via builtin “uaccess”); portanto, suas regras devem marcar não só add, mas também change (recomendado: ACTION!="remove", SUBSYSTEM=="hidraw", TAG+="uaccess"). Use udevadm verify/test para checar.
  • TPM2: inscrever sem se prender ao PCR 7: systemd-cryptenroll, systemd-repart e systemd-creds deixam de travar por padrão o enrollment ao valor literal do PCR 7 (que mede a política de Secure Boot). Como políticas de Secure Boot são atualizadas com frequência (via fwupd), o caminho preferido passa a ser o uso de políticas gerenciadas (systemd-pcrlock) e chaves públicas (incluindo assinaturas para PCR 11). Menos tijolos após atualizações de firmware, mais previsibilidade.

Essas mudanças reduzem arestas em três camadas críticas — terminais, dispositivos e raiz de confiança — sem sacrificar usabilidade.

(Para não confundir as esferas: DNF5 e Wayland são temas de distribuição/desktop; aqui estamos falando do núcleo de inicialização e serviços.)

Novas ferramentas para o administrador moderno

O v258 não é só faxina. Chegam peças novas que resolvem dores antigas e dão poder fino de observabilidade e controle.

  • ConditionKernelModuleLoaded=
    Nova condição de unidade para checar se um módulo já está carregado (ou é built-in). Isso permite pular modprobe redundante, acelerando o boot em kernels com subsistemas integrados — sem quebrar quem ainda precisa de módulos. Adeus “serviço de gambiarra” que só existia para garantir um modprobe a tempo.
  • Cotas por unidade em diretórios de serviço
    Agora é possível aplicar quota por projeto (XFS/EXT4) para os diretórios por-unidade: StateDirectoryQuota=, CacheDirectoryQuota= e LogsDirectoryQuota= (com as chaves de accounting correspondentes). Se um serviço está devorando /var/lib, /var/cache ou /var/log, você limita na fonte — e ainda enxerga os números direto no systemctl status. (Sem suporte a btrfs, por enquanto.)
  • API Varlink básica no PID 1
    O gerenciador de serviços passa a expor um endpoint Varlink para consultar estado e listar unidades. É uma interface leve, simples de consumir em scripts e ferramentas — especialmente útil em initrds e ambientes minimalistas onde você não quer puxar o ecossistema completo de D-Bus.
  • Credenciais criptografadas para serviços de usuário
    A infraestrutura de credentials do systemd (incluindo travas em TPM) agora também vale para o user manager. Isso permite padronizar fluxos “sem segredos no disco” inclusive em serviços por usuário.
  • Timers mais previsíveis
    RandomizedOffsetSec= chega aos .timer para introduzir jitter estável. Em clusters, isso ajuda a desincronizar picos de jobs sem gerar aleatoriedade imprevisível a cada boot. É o tipo de detalhe que evita tempestades de I/O às 00:00.
  • Rastreabilidade melhor na socket activation
    Instâncias Accept=yes incluem o SO_COOKIE e o inode do PIDFD do peer no nome, facilitando auditar “quem é quem” numa enxurrada de conexões. E systemctl start --verbose pode exibir logs ao vivo das unidades durante operações, reduzindo o vai-e-vem entre terminais.
  • Journald/journalctl mais “educados”
    journalctl --follow passa a encerrar com sucesso em SIGINT/SIGTERM e ganhou opção para sincronizar antes de sair, garantindo que o que foi enfileirado chegue ao disco. Em pipelines e forenses, isso evita perder justamente o final do rastro.
  • Udev com Varlink e depuração melhor
    Além do endurecimento de OWNER=/GROUP=, o udev oferece interface Varlink para operações de runtime, novos properties úteis (ex.: ID_AV_LIGHTS= para “luzes” USB de estúdio) e um udevadm test --verbose que torna a depuração de regras muito mais objetiva.
  • Networking e DNS mais previsíveis
    No systemd-networkd, chegam suportes como BOOTP no cliente DHCPv4, DAD IPv4 com timeout padrão de 200 ms, opções para MPLS e refinamentos no LLDP (inclusive VLAN). No systemd-resolved, surgem delegate zones para rotear domínios a servidores específicos, a possibilidade de recusar tipos de RR via RefuseRecordTypes= e timeouts A/AAAA mais inteligentes. Tudo isso ajuda a reduzir aquelas falhas “fantasmas” que só aparecem em redes complexas.
  • Factory reset de primeira classe
    A ferramenta systemd-factory-reset, com gerador dedicado e targets factory-reset-now/factory-reset, transforma pedidos de reset de fábrica em operações declarativas e seguras (inclusive via Varlink e EFI vars). Para imagens imutáveis e appliances, é ouro.
  • Teclas especiais: menos hacks, mais padrão
    O mapeamento “criativo” de teclas especiais (mute de microfone, toggle de touchpad) deixa o udev e vai para os drivers X11. Em outras palavras, menos remendos no user-space mais baixo e alinhamento com o caminho natural — boa notícia para quem está migrando de X11 para Wayland. Se você depende dessa compatibilidade, atualize xf86-input-evdev e xf86-input-libinput antes de adotar o v258.

O que vem por aí: descontinuamentos futuros

A equipe não só cortou o que precisava como avisou o próximo corte. Se você mantém distro, plataforma embarcada ou um grande parque, anote:

  • Scripts de serviço System V: deprecados já, remoção no v259.
    Se alguma peça ainda sobe via /etc/init.d, esta é a última chamada para escrever uma unidade nativa do systemd. Você ganha dependências explícitas, isolamento e sandboxing — e perde fontes de dor antigas.
  • /run/lock legado: deprecado, sai no v259.
    Softwares que ainda dependem desse diretório devem prover seu próprio tmpfiles.d (ou, melhor, migrar para RuntimeDirectory=/$XDG_RUNTIME_DIR, conforme o caso).
  • iptables (libiptc) no networkd/nspawn: adeus no v259.
    O backend passa a ser nftables apenas. Planeje conversões de regras e tooling — quanto antes você encostar no nft, menos surpresa terá na virada.
  • Pisos de versões mais altos já no radar
    Para o próximo ciclo, o projeto sinaliza elevar mínimos de kernel, bibliotecas e ferramentas (Linux ≥ 5.10, recomendado ≥ 5.14; glibc ≥ 2.34; openssl ≥ 3.0; libseccomp ≥ 2.4, entre outros). Se você produz imagens “long-term”, comece a sanear dependências agora para não descobrir incompatibilidades na véspera.

O que isso muda para você (e como agir)

Pense no v258 como uma redução de entropia: menos “jeitos antigos” convivendo com os novos e mais padrões seguros por padrão. Na prática:

  1. Faça um inventário rápido: identifique serviços e scripts que ainda assumem cgroup v1, runlevels ou scripts System V.
  2. Atualize kernels onde necessário: alinhar tudo em Kernel 5.4 (ou maior) diminui surpresas.
  3. Revise regras do udev: garanta que OWNER=/GROUP= não apontem para usuários comuns e ajuste o uso de TAG+="uaccess" conforme o novo fluxo.
  4. Aproveite as novas ferramentas: migre modprobes redundantes para ConditionKernelModuleLoaded=, avalie quotas por unidade para conter “gulodices” de disco e considere automações simples via Varlink.
  5. Planeje o futuro: converta o que resta de iptables para nftables e substitua de vez qualquer resquício de System V por unidades nativas.
Compartilhe este artigo