O desenvolvimento do systemd 258 entra em sua reta final com o lançamento da quarta versão candidata (rc4). Em termos práticos, isso é aquele “último apito do juiz”: a janela para a comunidade encontrar arestas, registrar regressões e validar migrações antes do carimbo de estabilidade. O rc4 já está publicado no repositório oficial — inclusive com changelog completo — reforçando que chegou a hora de testar agora, não “quando der”.
E há outro sinal de que o trem está chegando à estação: o rc4 começou a ser absorvido por distribuições para fase de integração. O Debian, por exemplo, já aceitou o pacote 258~rc4-1 no “unstable”, um passo típico de quem quer pegar cedo eventuais incompatibilidades. Para administradores e mantenedores, esse é o lembrete de que o cronômetro está rodando.
Reta final: systemd 258 se aproxima da versão estável
Mais do que “mais uma RC”, o rc4 fecha a narrativa de um ciclo que moderniza pressupostos do userspace Linux. A 258 consolida que o futuro — e o presente — é cgroup v2, que runlevels são passado, que kernels antigos deixam de ser baseline e que alguns fluxos de segurança e permissões mudam de lugar. Em outras palavras: é a revisão de “contratos” que muita infraestrutura assumia de forma tácita ao longo de anos. Tudo isso já está no CHANGES WITH 258 in spe e não depende de uma RC específica — o rc4 apenas marca que o pacote está pronto para a rua, salvo surpresas de última hora.
Relembrando as grandes mudanças: o que esperar no systemd 258
- Fim do cgroup v1: o suporte ao legado/híbrido foi removido; o cgroup v2 (hierarquia unificada) passa a ser montado sempre no boot e em
systemd-nspawn. Se você ainda vive decgroupfsv1, é hora de migrar. (GitHub) - Baseline do kernel 5.4 (recomendado 5.7): versões abaixo disso deixam de ser alvo de validação upstream. Em ambientes com LTS antigos, revise planos de kernel.
- Adeus aos runlevels: o controle de estado ao estilo SysV foi removido (nada de
/dev/initctl,init 3,runlevel*.targetetc.). Ferramentas/rotinas que ainda esperam essas interfaces precisam de alternativas nativas do systemd. - Scripts SysV: ainda funcionam hoje, mas estão deprecados e serão removidos na v259. Traduza-os para unidades nativas já, para não descobrir o problema no próximo ciclo.
- TTY/PTS mais restritos: o modo padrão de acesso dos dispositivos passou de 0620 para 0600 — pense nisso como “
mesg npor padrão”. Se algum fluxo dependia de escrita de outros usuários no terminal, ajuste. - Crypto unificada: OpenSSL passa a ser a única biblioteca suportada para
systemd-resolvedesystemd-importd(suporte a GnuTLS/gcrypt removido). Avalie impactos em builds e em políticas de compliance. - Regras de udev “uaccess” mudam de lugar: as ACLs deixam de ser aplicadas pelo
loginde passam a ser responsabilidade dosystemd-udevd. Suas regras devem marcar o dispositivo também em eventos change (não só em add). - Limpeza de compatibilidade antiga no boot: arquivos “de força” como
/forcefscke/forcequotachecksaem de cena; agora o controle é via parâmetros de kernel/credenciais (fsck.mode=,quotacheck.mode).
Parece muita coisa? É — mas é o tipo de “troca de trilhos com o trem em movimento” que, feita na rc4, evita dor de cabeça quando a estável pousar nos repositórios.
Checklist prático para atualizar sem sustos
- Cgroup v2 em produção
Confirme que sua máquina está em hierarquia unificada (test -f /sys/fs/cgroup/cgroup.controllers). Contêineres que ainda esperam cgroup v1 tendem a falhar de formas sutis; alinhe runtimes/opções antes do upgrade. - Kernel suportado
Garanta baseline ≥ 5.4 (idealmente ≥ 5.7). Em parques heterogêneos, priorize hosts com kernels legados para pilotos controlados e tenha plano de rollback. - Caça aos SysV
Varra o parque por serviços gerados pelosystemd-sysv-generator(dica: procure por units marcadas como “generated” ou por resquícios em/etc/init.d). Converta para unidades nativas antes de a v259 bater na porta. - Permissões de TTY
Se há scripts que escrevem em TTYs de outros usuários (broadcasts, notificações), reavalie: com 0600 por padrão, parte desse comportamento pode deixar de funcionar. Ajuste políticas e automatizações. - Builds e compliance com OpenSSL
Cheque pipelines, flags de Meson e políticas de criptografia corporativa. Se você mantinha variantes com GnuTLS, é hora de unificá-las em OpenSSL. - Regras udev
Atualize regras que usam TAG=”uaccess” para também cobrir ACTION==”change”; teste dispositivos de entrada/HID e fluxos de login não gráficos. - Boot e manutenção
Se sua automação dependia de/forcefsck//forcequotacheck, troque porfsck.mode=/quotacheck.mode=via kernel cmdline/credenciais.
Por que isso importa?
Porque as mudanças acima afetam a base sobre a qual distribuímos e operamos Linux. O rc4 não é “só” mais um tarball: é o ensaio geral — aquele momento de rodar o playbook de migração com dados reais, abrir issues se necessário e fechar lacunas antes da versão final. E, dado que algumas distros já estão empacotando o rc4, o relógio está marcando em tempo de produção.
