daltux

Acaba sendo bastante interessante pelo menos alguém, em uma equipe que trabalha com um parque repleto de Debian GNU/Linux e/ou derivados como Ubuntu, utilizar Debian Sid ou pelo menos Testing na sua máquina de uso direto: pode ser possível antecipar as eventuais mudanças relevantes na distribuição, por ficar sabendo delas mais naturalmente e provavelmente ter que tratá-las ali assim que ocorrerem, bem antes das máquinas de produção.

Isso ainda permite minimamente contribuir com o teste do sistema operacional utilizado (normalmente) gratuitamente para seu sustento, sendo um projeto colaborativo. Acaba se acostumando a se desvencilhar de possíveis problemas em atualizações, bem como a manipular suas ferramentas e métodos mais recentes. Enfim, aprimorar-se mais do que se não fizesse isso.

Fica menos fácil se utilizar distribuições em formato distinto daquela predominante no seu parque. Muito mais difícil se fizer como muitos que teimam até em usar outros sistemas operacionais que não se justificam além das massas. Pior ainda, aqueles com arquiteturas totalmente proprietárias, específicas, longe dos padrões POSIX.

Esse conceito veio após o exemplo que segue.

Mensagem exibida ao se atualizar o pacote sudo do sid nesta sexta-feira, 2023-12-08:

apt-listchanges: News

sudo (1.9.15p2-1) unstable; urgency=medium

sudo-ldap has become a burden to maintain. This is mainly due to the fact that the sudo team has neither the manpower nor the know-how to maintain sudo-ldap adequately.

In practice, there are few installations that use sudo-ldap. Most installations that use LDAP as a directory service and sudo have now opted for sssd, ssdh-ldap and libsss-sudo.

The Debian sudo team recommends the use of libsss-sudo for new installations and the migration of existing installations from sudo-ldap to libsss-sudo and sssd.

The combination of sudo and sssd is automatically tested in autopkgtest of sudo.

This is also being discussed in #1033728 in the Debian BTS.

Debian 13, “trixie”, will be the last version of Debian that supports sudo-ldap. Please use the bookworm and trixie release cycles to migrate your installation away from sudo-ldap.

Please make sure that you do not upgrade from Debian 13 to Debian 14 while you're still using sudo-ldap. This is not going to work and will probably leave you without intended privilege escalation.

— Marc Haber mh+debian-packages@zugschlus.de Mon, 20 Nov 2023 10:07:57 +0100

Em suma, a equipe reponsável pelo empacotamento do sudo declara que trixie — codinome da versão em testing atual, a ser eventualmente paralisada para ser lançada como Debian 13, ainda sem data — será a última versão de Debian com disponibilidade do pacote sudo-ldap.

Felizmente, em máquinas mais recentes, acaba sendo mais frequentemente usado sssd para a integração com o LDAP por ser o que possui mais instruções na documentação, e é realmente uma alternativa apontada pela equipe do sudo agora.

Como Ubuntu é filho de Debian, as mudanças deste devem chegarão em algum momento a Ubuntu também. Nesse caso, se continuarem o padrão atual, provavelmente até 2026.

Claro que seria também possível manter máquinas no parque de servidores para testes com Debian sid ou testing, que precisariam ser frequentemente manipuladas, ou talvez seguir as listas de discussão (difícil por serem inúmeras), porém as atitudes não são excludentes.

🇧🇷🇵🇹 Este blogue © 2023-25 por Daltux é publicado sob a licença CC BY-SA 4.0.
🇨🇦🇬🇧 This blog © 2023-25 by Daltux is licensed under CC BY-SA 4.0.  🅭 🅯 🄎

Seguem resultados de um rápido #teste de desempenho de leitura de dispositivos de armazenamento de dados comuns em algumas máquinas. São quatro unidades de discos rígidos (HDD), duas unidades de estado sólido (SSD) e um cartão de memória MicroSD. Os testes foram realizados utilizando o software GNOME Disks enquanto as partições existentes estavam montadas, ainda que sem uso intenso.

O SSD contido no laptop com #Ubuntu 18.04, em especial, está em uso há dez anos ou mais e já passou por três máquinas como dispositivo de armazenamento principal. Já soma mais de um ano ligado e não apresenta erros, segundo dados de SMART apresentados pelo GNOME Disks. Foi o mais barato de fabricante razoavelmente confiável (SanDisk no caso) encontrado à época.

Com a recente ampla disponibilidade de interação da máquina com o SSD por NVMe, a diferença de acesso aos dados tende a ser mais gritante ainda.

Apesar de não ter sido feito teste de gravação (há inúmeros disponíveis), a conclusão óbvia é a de que, por mais simples que seja o SSD, já está décadas à frente em quesito desempenho e se equipara ou talvez até ultrapasse em durabilidade, portanto passamos da hora de abolir os HDs no cotidiano.

Laptop com Ubuntu 22.04

HD principal (SATA)

HD externo (USB) Samsung M3 Portable

Laptop com Ubuntu 18.04

SSD (SATA) contendo partição principal (dados do sistema e de usuários)

HD (SATA) contendo partições secundárias (swap, NTFS entre outras)

Desktop com Ubuntu 18.04

SSD (SATA) contendo partição principal (/)

HD (SATA) contendo partição do usuário (/home)

Raspberry Pi 3 Model B

MicroSD classe 10

#hardware

🇧🇷🇵🇹 Este blogue © 2023-25 por Daltux é publicado sob a licença CC BY-SA 4.0.
🇨🇦🇬🇧 This blog © 2023-25 by Daltux is licensed under CC BY-SA 4.0.  🅭 🅯 🄎

Última revisão: 13/11/2023

Ubuntu, recentemente (22.04^[1] em diante), na sua variação para desktop, inclui um serviço “systemd-oomd” que mata processos que estejam consumindo muita memória, preventivamente, bem antes que ela se esgote e haja potencial travamento. A ideia parece boa, porém, como está implementada, acaba sendo exagerada.

Não adianta disponibilizar mais swap^[2], pois o novo mecanismo entra em ação quando qualquer processo (leia-se provavelmente o navegador) tem a tendência de ocupar mais do que 50% da RAM por mais de 20s, por padrão. Pode conferir suas definições executando oomctl. Mesmo alterar as configurações (em /etc/systemd/oomd.conf) parece não solucionar, pois, no fim, impede que o usuário ocupe toda a memória.

Na prática comum, se a máquina não tiver muita RAM sobrando, o navegador, ao ser utilizado mais intensamente, acaba sendo fechado bruscamente, enquanto ainda praticamente nem foi usada swap. Pior que, se não olhar o syslog^[3] (ou journalctl^[4]), o usuário nem fica sabendo por quê^[5]. Talvez culpe a aplicação. Havendo escassez de RAM, isso pode acontecer com qualquer programa razoavelmente espaçoso como, por exemplo, enquanto edita uma planilha ou outro arquivo, ou desenvolve um sistema. Há relatos^[6] de que, dependendo da situação, até aquele que chamou os processos pode vir a ser encerrado, como seu terminal ou a área de trabalho completa. Portanto, há risco de perder dados não salvos.

Independentemente do que tentam sistemas operacionais, utilitários ou aplicativos para mitigar a questão, é claro que utilizar uma máquina com memória insuficiente terá efeitos indesejados ou será até inviável. Swap felizmente permite que mais memória esteja disponível para processos em execução, tendo o efeito adverso de lentidão ao transferir páginas de memória para/do armazenamento, sobretudo se este for mecânico^[7]. O “systemd-oomd”, por matar processos antes que ocupem toda a memória, dá uma falsa sensação de menos travamento. Entretanto, o preço a pagar por essa comodidade é alto.

O que se pode fazer, por enquanto, data venia, é contrariar a Canonical (empresa que mantém o Ubuntu) e retornar ao que sempre funcionou, bem ou mal: confiar apenas no próprio Kernel (Linux) para matar emergencialmente os processos mais vorazes somente quando estiver esgotada a memória total, incluindo swap. É uma situação extrema em que já não há mais memória disponível, gerando congelamento até que o #Kernel, vagarosamente, consiga recuperar memória suficiente para os processos sobreviventes continuarem a execução. Essa problemática foi a motivação de Ubuntu incluir tal serviço paralelo, para evitar esse tipo de travamento. Contudo, acaba podendo ser pior.

É possível desabilitar o systemd-oomd com: sudo systemctl disable --now systemd-oomd.service

Mas, isto não garante que ele não seja invocado posteriormente por algum outro serviço. De fato, mesmo com o serviço desabilitado, ele pode acabar sendo encontrado em execução após um reboot, gerando os mesmos sintomas. Uma alternativa seria “mascará-lo”: sudo systemctl mask systemd-oomd ^[8]

A mais eficaz e definitiva solução é desinstalar o pacote systemd-oomd^[9]. Não há dependentes, portanto não há impedimento:

sudo apt remove --purge systemd-oomd

Se, futuramente, o funcionamento de tal mecanismo for aperfeiçoado, ou se mudar de ideia, basta reinstalar esse pacote.

Observação

O texto está focado no #Ubuntu pois era uma distribuição que o autor utilizava no cotidiano à época da redação, todavia também é válido para outras que trazem o “systemd-oomd”, como Fedora ≥34.^[10]

---

[1] Ubuntu 22.04 LTS lançado em abril de 2022. Confira os detalhes (em inglês). [2] Mecanismo de memória virtual: partição ou arquivo de troca de paginação de memória física para disco que permite ter mais memória livre. [3] Registro de eventos do sistema, geralmente disponível no arquivo /var/log/syslog. [4] Saiba como utilizar o journalctl para visualizar mensagens do systemd. [5] Cf. relato de bug do systemd. [6] Cf., p. ex., https://techhq.com/2022/07/ubuntu-22-oomd-app-killer-memory-pressure/, https://bugzilla.redhat.com/show_bug.cgi?id=1941340, https://bugzilla.redhat.com/show_bug.cgi?id=1933494, https://askubuntu.com/questions/1404888 [7] Há maneiras de otimizar um pouco o uso de swap atualmente, como zswap ou zram, boas sugestões. Confira ainda um texto do Arch Linux a respeito (em inglês), incluindo outras opções de limpeza automática de memória similares ao “systemd-oomd”. [8] Cf. https://www.cjjackson.dev/posts/what-is-systemd-oomd-how-to-disable-it/ [9] Cf. https://askubuntu.com/a/1423840/1007603 [10] Cf. relato de bug de 2021.

#systemd #RAM #Ubuntu #Fedora #GNU #Linux #swap

🇧🇷🇵🇹 Este blogue © 2023-25 por Daltux é publicado sob a licença CC BY-SA 4.0.
🇨🇦🇬🇧 This blog © 2023-25 by Daltux is licensed under CC BY-SA 4.0.  🅭 🅯 🄎

Orgulhava-me por conseguir usar celulares até acabarem, desistindo apenas quando literalmente quebravam ou a reposição da bateria ficava inviável. Já fiz vários “ressuscitarem”, após deixarem de ter atualizações das fabricantes, instalando geralmente alguma versão de LineageOS (Cyanogenmod anteriormente), uma distribuição comunitária com atualização frequente do Android, sistema operacional cujas partes genéricas, incluindo o Kernel Linux, têm o código-fonte aberto. Código-fonte é a programação escrita que pode ser estudada, auditada e/ou reaproveitada. As fabricantes dos aparelhos adicionam ao #Android componentes específicos para cada modelo e normalmente promovem outras adaptações e personalizações, muitas vezes sem disponibilizar o código-fonte, infelizmente. Então, cabe normalmente a programadores voluntários da comunidade portar ou até reimplementar componentes necessários para que a distribuição alternativa funcione em determinado dispositivo.

A #Samsung teve a “brilhante” ideia de colocar em alguns modelos um mecanismo que impede qualquer tipo de alteração “não oficial” no firmware, software embutido na máquina, sendo que o bootloader, processo que carrega o sistema operacional ao ligar, poderia ser desbloqueado, o que possibilitaria instalar versões diferentes, apenas após uma semana de funcionamento com o mesmo cartão SIM (chip da operadora). Esta condição é validada por um servidor na Internet mantido pela empresa. Isso supostamente serviria para inviabilizar alterações caso o aparelho fosse extraviado. Ocorre que a Samsung não deu a devida manutenção a tal servidor rmm.samsung.com, cujo certificado para HTTPS se expirou em fins de 2021. Ou seja, agora o celular se recusa a se comunicar com o serviço que validaria sua situação para que permitisse desbloquear o bootloader nas opções de desenvolvedor.

Então é isto: ficamos com um aparelho que teve a última atualização em 2020, no caso do Galaxy A5 2017, e agora não podemos fazer mais nada a respeito. Após seis anos, o hardware está perfeito, a tela não tem um risco e até a bateria ainda está surpreendentemente útil. Porém, a obsolescência programada venceu.

Aparentemente, pouco adianta ser cuidadoso com algo feito para durar no máximo três anos. Que fazer agora? Jogar fora e poluir? Vender a preço de banana? Sugestões são bem-vindas.

Há informações a quem quiser ver que não sou o único a passar por isso no fórum especializado XDA.

Post scriptum

A ideia era experimentar LineageOS for microG, sendo microG uma implementação livre alternativa aos Google Play Services, ou seja, Android sem a dependência destes, para não oferecer tantos dados pessoais à empresa que domina o mercado.

🇧🇷🇵🇹 Este blogue © 2023-25 por Daltux é publicado sob a licença CC BY-SA 4.0.
🇨🇦🇬🇧 This blog © 2023-25 by Daltux is licensed under CC BY-SA 4.0.  🅭 🅯 🄎