daltux

Instabilidade no Ubuntu: motivo e solução

19 de julho de 2023

Ú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

Obsolescência programada Samsung venceu

09 de julho de 2023

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.