Explicação dos valores exibidos nas telas htop/top do Linux (2019)

• Partindo da tela do htop no Ubuntu Server 16.04 x64, acompanha via /proc e saídas de comandos o que uptime, load average, Tasks, PID, árvore de processos, estado, tempo de CPU, prioridade e métricas de memória realmente significam
• Muitos valores da tela vêm do procfs e de arquivos do sistema como /etc/passwd, /etc/group, /etc/shadow e /etc/nsswitch.conf; com strace, é possível verificar quais arquivos o programa lê
• Load average não é o mesmo que uso de CPU; é uma média móvel com decaimento exponencial que inclui processos em execução, processos aguardando para executar e processos em estado uninterruptible
• Códigos de estado como R, S, D, Z, T e t estão ligados a signal, kill e ao comportamento de fork/exec/wait, servindo como pistas para entender por que um processo parou ou continua presente
• VIRT, RES, SHR e MEM% mostram memória virtual, memória física e memória potencialmente compartilhável sob perspectivas diferentes, portanto é difícil concluir o uso real de memória olhando apenas um número

---

De onde vêm os valores do htop

• uptime mostra há quanto tempo o sistema está em execução; a mesma informação também pode ser verificada com o comando uptime
• O programa uptime lê /proc/uptime
  • O primeiro número é o tempo total, em segundos, desde que o sistema foi ligado
  • O segundo número é o tempo, em segundos, em que o sistema esteve em estado idle
  • Em sistemas multicore, o tempo idle pode ser somado por núcleo e ficar maior que o uptime total
• Com strace uptime 2>&1 | grep open ou strace -e open uptime, é possível ver os arquivos que o uptime abre
  • A saída de exemplo inclui /proc/uptime, /var/run/utmp e /proc/loadavg
• Os números de /proc/uptime são convenientes para programas ou scripts, enquanto a saída de uptime é formatada para leitura humana

Load average e uso de CPU

• Os três primeiros valores de /proc/loadavg representam o load average do sistema nos últimos 1 minuto, 5 minutos e 15 minutos
• O quarto valor mostra o número de processos em execução e o número total de processos, como 1/120, e o último valor é o último PID usado
• Ao executar um novo processo, um PID é atribuído; em geral, os PIDs aumentam e, quando se esgotam, são reutilizados
  • O PID 1 pertence a /sbin/init, iniciado durante o boot
• Se no htop aparecer apenas um processo em execução, esse processo pode ser o próprio htop
• sleep 30 não está em execução, mas em estado sleep, portanto não aumenta o número de running processes
• Uma tarefa que usa CPU continuamente, como cat /dev/urandom > /dev/null, aumenta o número de running processes e o load average
• O load number é um valor que conta processos em execução ou aguardando para executar, além de processos em estado uninterruptible
• O load average não é uma média simples, mas uma média móvel com decaimento exponencial
  • Mesmo o load average de 1 minuto não reflete apenas os últimos 60 segundos; ele dá mais peso ao último minuto, mas também inclui parte da atividade anterior
• Em um sistema com uma única CPU, se houver um processo CPU-bound, o load average 1.00 pode ser simplificado como 100% de uso da CPU
  • Em um sistema de 2 núcleos, a mesma situação pode ser vista como 50% de uso da CPU
  • Em um sistema de 2 núcleos, o load average correspondente a 100% de uso da CPU pode ser simplificado como 2.00
• Essa simplificação nem sempre é correta, porque processos em estado uninterruptible são incluídos no load
  • Também é possível haver load average alto sem uso de CPU elevado
• O uso instantâneo de CPU pode ser verificado com mpstat
  • sudo apt install sysstat -y
  • mpstat 1

Tasks, PID e árvore de processos

• Tasks, no canto superior direito do htop, mostra o número total de processos e o número de processos em execução
• Internamente, o kernel Linux chama processos de tasks, e o htop usa Tasks em vez de Processes para economizar espaço na tela
• Com Shift+H, é possível alternar a exibição de threads
  • Se aparecer algo como Tasks: 23, 10 thr, as threads estão sendo exibidas
• Com Shift+K, é possível alternar a exibição de kernel threads
  • Se aparecer algo como Tasks: 23, 40 kthr, as kernel threads estão sendo exibidas
• Sempre que um novo processo é iniciado, um PID é atribuído
  • Ao executar em segundo plano, como sleep 1000 &, o número do job e o PID são exibidos
  • $! no bash se expande para o ID do último processo em segundo plano
• Informações relacionadas a processos ficam em /proc/<pid>/
  • /proc/<pid>/cmdline contém o comando executado, e os argumentos são separados por bytes \0
  • É possível visualizar de forma legível com tr '\0' '\n' < /proc/<pid>/cmdline ou strings /proc/<pid>/cmdline
  • /proc/<pid>/cwd é um link para o diretório de trabalho atual, e /proc/<pid>/exe é um link para o binário executado
• Ferramentas de diagnóstico como htop, top e ps leem detalhes dos processos em /proc/<pid>/<file>
• Quem cria um novo processo é o parent process, e o processo recém-criado é o child process; essa relação forma a árvore de processos
• Ao pressionar F5 no htop, é possível ver a hierarquia de processos
  • ps f e pstree -a também mostram a mesma relação
• Ao executar date no bash, o bash cria uma cópia de si mesmo com fork, carrega /bin/date na memória com exec e, em seguida, o bash parent aguarda o término do child
• /sbin/init é iniciado no boot e sobe o sshd; ao fazer login por SSH, o sshd cria o processo de sessão, e essa sessão executa o shell bash

Usuário e permissões de processos

• Cada processo pertence a um usuário, e o usuário é representado por um ID numérico
• É possível verificar o ID de usuário de um processo no item Uid de /proc/<pid>/status
• Um comando como id 1000 mostra o nome de usuário e os grupos correspondentes ao ID numérico
• id escolhe as fontes de resolução de nomes conforme a configuração de /etc/nsswitch.conf
  • No sistema de exemplo, ele lê /etc/passwd e /etc/group
  • compat é o modo de compatibilidade e é igual a files, mas permite entradas especiais
  • As informações de usuários também podem ser armazenadas em outros bancos de dados ou serviços, como LDAP
• /etc/passwd e /etc/group são arquivos em texto puro que mapeiam IDs numéricos para nomes legíveis por humanos
• As informações reais de senha ficam em /etc/shadow
  • $6$ indica o algoritmo de hash sha512
  • Depois disso vêm um salt aleatório para evitar ataques de rainbow table e o hash de password+salt
• Por padrão, programas são executados com as permissões do usuário que os executou
  • Isso é igual mesmo que o proprietário do executável seja outro usuário
• Para executar como outro usuário ou como root, usa-se sudo
  • sudo id é executado com o UID 0 de root
  • É possível executar como um usuário específico, como em sudo -u daemon id
• Ao tentar escrever diretamente em /etc/sudoers com redirect, apenas o echo é executado como root e o append é feito como o usuário atual, podendo falhar
  • echo "$USER ALL=(ALL) NOPASSWD: ALL" | sudo tee -a /etc/sudoers
  • sudo bash -c "echo '$USER ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers"
• /etc/sudoers deve ser editado com sudo visudo
  • Ele valida o conteúdo antes de salvar, evitando erros que possam deixar sudo inutilizável
• /usr/bin/passwd consegue escrever em /etc/shadow mesmo quando executado por um usuário comum
  • Como há um s nas permissões do arquivo, ele funciona como um executável setuid
  • É executado com as permissões de root, o proprietário do executável
  • Executáveis setuid pertencentes a root podem ser encontrados com find /bin -user root -perm -u+s

Códigos de estado de processos

• A coluna de estado do htop aparece com o nome S, e os principais valores são os seguintes
  • R: running ou runnable, em execução ou aguardando na fila de execução
  • S: interruptible sleep, aguardando a conclusão de um evento
  • D: uninterruptible sleep, normalmente aguardando I/O
  • Z: defunct zombie, encerrado, mas ainda não coletado pelo parent
  • T: parado por job control signal
  • t: parado por um debugger durante tracing
  • X: dead, estado que não deveria aparecer
• ps também mostra substates como Ss, R+ e Ss+

• R: em execução ou executável

  • O estado R indica que o processo está em execução no momento ou aguardando na fila de execução
  • O código-fonte de um programa, depois de compilado, vira instruções de CPU e, ao ser executado, é carregado na memória para que a CPU execute essas instruções
  • Estar em execução significa que a CPU está executando fisicamente as instruções

• S: sleep interrompível

  • No estado S, as instruções do processo não são executadas pela CPU; ele aguarda um evento ou condição
  • Quando o evento ocorre, o kernel muda o estado para running
  • sleep 1000 é um exemplo de espera por um tempo especificado
  • Esse estado pode ser interrompido por um signal
  • No htop, é possível enviar um signal pressionando F9
  • kill é uma chamada de sistema que envia um signal, e /bin/kill é um programa em userland que chama essa funcionalidade
  • O signal padrão é TERM, que solicita o encerramento do processo
  • Signals são números; seus nomes normalmente são escritos em maiúsculas e podem ter o prefixo SIG
  • Exemplos: INT, KILL, STOP, CONT, HUP
  • kill -INT 10089, kill -2 10089 e /bin/kill -2 10089 fazem a mesma coisa
  • Ao pressionar CTRL+C, o bash envia SIGINT para o foreground process
  • Enviar SIGINT ou SIGTERM não significa que o processo necessariamente será encerrado
  • Um programa pode definir um signal handler para fazer tarefas de limpeza e então encerrar
  • SIGKILL ou 9 faz o kernel encerrar o processo à força, sem dar a ele a chance de responder

• D: sleep não interrompível

  • O estado D não pode ser acordado por signals; como SIGKILL também é um signal, não é possível matar esse tipo de processo
  • Esse estado é usado quando o processo precisa esperar sem interrupção ou quando se espera que o evento ocorra rapidamente
  • Exemplo: leitura/escrita em disco
  • Um processo uninterruptible pode normalmente estar aguardando I/O após um page fault
  • Esse estado pode ocorrer com atrasos de leitura e escrita em NFS
  • Também pode aparecer quando há tão pouca memória disponível que o processo passa a fazer muito swap
  • Como exemplo, ao executar sudo mount 8.8.8.8:/tmp /tmp &, /sbin/mount.nfs fica no estado D
  • Vendo com strace, a chamada de sistema mount bloqueia o processo
  • Ao passar a opção intr para mount, é possível executá-lo de forma interruptible
  • sudo mount 8.8.8.8:/tmp /tmp -o intr

• Z: processo zumbi

  • O estado Z indica que o processo foi encerrado, mas o parent ainda não fez reap dele
  • Processos zumbis podem ser normais se existirem por pouco tempo
  • Processos zumbis que permanecem por muito tempo podem indicar um bug no programa
  • Um processo zumbi não consome memória, apenas ocupa um PID
  • O processo zumbi em si não pode ser morto com kill
  • É possível enviar SIGCHLD ao parent process para pedir que ele faça reap do zumbi
  • Ao matar o parent process, é possível remover o parent e seu zumbi
  • É possível reproduzir o estado zumbi com um programa em C que, após fork, faz o child chamar exit(0) e o parent chamar sleep(20)
  • Quando o parent termina, o zumbi desaparece
  • O motivo de o zumbi ser mantido é que o parent precisa poder verificar o exit code do child pela chamada de sistema wait

• T e t: processos parados

  • O estado T indica que o processo foi parado por um job control signal
  • Ao pressionar CTRL+Z durante a execução de cat /dev/urandom > /dev/null, ele entra no estado T
  • É possível retomá-lo com fg
  • Também é possível pausá-lo com o signal STOP e retomá-lo com o signal CONT
  • O estado t indica que o processo está parado enquanto um debugger faz tracing
  • Ao fazer attach com sudo gdb -p <pid> a um processo executado com nc -l 1234 &, ele entra no estado t

Tempo de CPU, niceness e prioridade

• O Linux é um sistema operacional multitarefa, então, mesmo em uma única CPU, vários processos parecem estar em execução ao mesmo tempo
• Na prática, uma única CPU só consegue executar uma instrução por vez, por isso usa time sharing
  • Um processo é executado por um curto período e depois é interrompido
  • Outros processos aguardando execução são executados em sequência
  • O curto intervalo em que um processo é executado é chamado de time slice
• Como o time slice geralmente dura alguns milissegundos, isso quase não é perceptível se a carga do sistema não estiver alta
• Em um único núcleo, se o load average for 1.0, pode-se considerar que a CPU foi usada 100%
  • Se for maior que 1.0, há mais processos tentando executar do que a CPU consegue processar, o que pode causar slowdown ou delay
  • Se for menor que 1.0, a CPU fica ociosa em alguns momentos
• O motivo pelo qual o running time de um processo pode não ser exatamente igual ao tempo real decorrido também é explicado pelo time sharing
• Se houver mais tasks a executar do que CPUs core disponíveis, é preciso decidir qual task será executada primeiro
• O scheduler do kernel Linux escolhe o próximo processo na run queue, dependendo do algoritmo de scheduling do kernel
• Em geral, não é possível controlar diretamente o scheduler, mas é possível indicar quais processos são mais importantes
• niceness, exibido como NI, é a prioridade em user-space
  • O intervalo vai de -20 a 19
  • -20 é a prioridade mais alta e 19 é a mais baixa
  • Pode-se entender que um processo mais nice cede mais espaço a processos menos nice
• PRI é a prioridade em kernel-space usada pelo kernel Linux
  • O intervalo vai de 0 a 139
  • 0~99 é para real time, e 100~139 é o intervalo para usuários
• A relação entre o valor nice e a priority é explicada por PR = 20 + NI
  • -20~+19 de NI vira 0~39 de PR, que é mapeado para 100~139
• Antes da execução, a niceness é definida com nice -n niceness program
• A niceness de um processo em execução é alterada com renice -n niceness -p PID
• As cores de uso de CPU são as seguintes
  • Blue: thread de baixa prioridade, nice > 0
  • Green: thread de prioridade normal
  • Red: kernel thread

Métricas de memória: VIRT, RES, SHR, MEM%

• Um processo parece existir sozinho na memória, e isso é implementado por meio de memória virtual
• Um processo não acessa diretamente a memória física; ele tem seu próprio virtual address space
• O kernel pode converter virtual memory address em physical memory ou mapear parte dela para o disk
• Por isso, um processo pode parecer usar mais memória do que a instalada no computador
• O uso de memória de um processo varia conforme inclui ou não os seguintes itens
  • shared library
  • disk-mapped memory
  • swapped out memory
• As cores de uso de memória são as seguintes
  • Green: used memory
  • Blue: buffers
  • Orange: cache

• VIRT/VSZ

  • VIRT é a quantidade total de virtual memory usada pela task
  • Inclui code, data, shared library, swapped out page e pages mapeadas mas não usadas
  • Mesmo que uma aplicação solicite 1 GB e use apenas 1 MB, VIRT pode aparecer como 1 GB
  • Mesmo que um arquivo de 1 GB seja mapeado com mmap e não seja usado de fato, VIRT pode ser exibido como 1 GB
  • Na maioria dos casos, VIRT não é um número útil

• RES/RSS

  • RES é a physical memory que não foi swapped out, ou seja, o uso de resident memory atualmente presente na memória física
  • RES pode representar melhor o uso real de memória do que VIRT, mas tem limitações
  • Não inclui swapped out memory
  • Parte da memória pode ser compartilhada com outros processos
  • Se um processo usar 1 GB de memória e depois fizer fork(), o RES dos dois processos pode aparecer como 1 GB cada, mas, devido ao copy-on-write do Linux, na prática apenas 1 GB pode estar sendo usado

• SHR

  • SHR é a quantidade de shared memory usada pela task
  • Reflete a memória que pode ser potencialmente compartilhada com outros processos
  • Um programa de exemplo em C mostra como os valores de VIRT, RES e SHR mudam ao passar por malloc, uso de parte da memória, fork e escrita adicional na memória
  • A seção do exemplo de memória correspondente permanece como TODO

• MEM%

  • MEM% é a proporção de available physical memory usada atualmente pela task
  • É o valor de RES dividido pela RAM total
  • Ex.: se RES for 400M e a RAM for 8 GB, 400/8192*100 = 4.88%

Processos básicos do Ubuntu Server 16.04

• Foram investigados os processos iniciados em um Ubuntu Server 16.04.1 LTS x64 de um droplet novo da DigitalOcean

• /sbin/init

  • /sbin/init coordena o restante do processo de boot e configura o ambiente do usuário
  • Torna-se o processo pai ou avô dos processos iniciados automaticamente
  • O resultado de dpkg -S /sbin/init é systemd-sysv: /sbin/init, portanto nesse sistema trata-se do systemd
  • Nada acontece mesmo se for morto

• /lib/systemd/systemd-journald

  • systemd-journald é um serviço de sistema que coleta e armazena dados de logging
  • Cria e mantém um journal estruturado e indexado com base em informações de log recebidas de várias fontes
  • Em vez de arquivos de log simples em texto puro, usa um formato de arquivo especial otimizado para mensagens de log
  • Consultado com journalctl
  • journalctl _COMM=sshd
  • journalctl _COMM=sshd -o json-pretty
  • journalctl --since yesterday
  • journalctl -b
  • journalctl -f
  • journalctl --disk-usage
  • journalctl --vacuum-size=1G
  • Parece não ser possível removê-lo ou desativá-lo; apenas desligar o logging

• /sbin/lvmetad -f

  • lvmetad faz cache dos metadados do LVM para que comandos LVM leiam os metadados sem fazer varredura de disco
  • A varredura de disco leva tempo e pode atrapalhar as operações normais do sistema e do disco
  • O LVM pode ser visto como “partições dinâmicas” que permitem criar, redimensionar e excluir volumes lógicos enquanto o Linux está em execução
  • A conclusão é que, se você estiver usando LVM, deve mantê-lo

• /lib/systemd/udevd

  • systemd-udevd escuta uevents do kernel e, para cada evento, executa as instruções correspondentes das regras udev
  • udev é o gerenciador de dispositivos do kernel Linux e gerencia principalmente os nós de dispositivo no diretório /dev
  • Não há certeza se ele é necessário em um servidor virtual

• /lib/systemd/timesyncd

  • systemd-timesyncd é um serviço de sistema que sincroniza o relógio local do sistema com um servidor NTP remoto
  • Substitui o ntpd
  • No sistema de exemplo, timedatectl status mostra network time e NTP synchronized como yes
  • Na saída do netstat, apenas a porta SSH aparece em estado de listening; ele não abre várias portas UDP 123 como o ntpd do Ubuntu 14.04

• /usr/sbin/atd -f

  • atd executa jobs colocados na fila para serem executados mais tarde
  • at e batch leem comandos do stdin ou de um arquivo e os executam posteriormente
  • Diferentemente do cron, que agenda execuções recorrentes, at executa uma vez em um horário específico
  • No exemplo, echo "touch /tmp/yolo.txt" | at now + 1 minute cria um arquivo após 1 minuto
  • Se não for usado, remova com sudo apt remove at -y --purge

• /usr/lib/snapd/snapd

  • O Snappy Ubuntu Core é apresentado como uma versão do Ubuntu que usa atualizações transacionais
  • snap é descrito como um formato universal de pacote Linux que permite que um único pacote binário funcione em desktops, servidores, cloud e dispositivos Linux
  • Pode ser entendido como um pacote deb simplificado que agrupa dependências em um único snap para distribuição
  • Como nunca foi feito deploy ou distribuição de aplicações com snappy no servidor, foi removido com sudo apt remove snapd -y --purge

• /usr/bin/dbus-daemon

  • D-Bus é um mecanismo de IPC e RPC entre vários processos executados simultaneamente na mesma máquina
  • É necessário em ambientes desktop, mas fica a dúvida se é necessário em um servidor que executa uma web app
  • Ao remover dbus, timedatectl status falhou com Failed to create bus connection: No such file or directory
  • Por isso, a conclusão é que é melhor mantê-lo

• /lib/systemd/systemd-logind

  • systemd-logind é um serviço de sistema que gerencia logins de usuários

• /usr/sbin/cron -f

  • cron é um daemon que executa comandos agendados
  • -f significa foreground mode, sem daemonizar
  • Tarefas a serem executadas periodicamente podem ser agendadas com cron
  • crontab -e
  • A conclusão é que, no Ubuntu, costuma-se usar /etc/cron.hourly, /etc/cron.daily etc.
  • Os logs podem ser vistos das seguintes formas
  • grep cron /var/log/syslog
  • journalctl _COMM=cron
  • journalctl _COMM=cron --since="date" --until="date"
  • É bem provável que o cron seja mantido
  • Se não for removê-lo, é possível parar e desativar com sudo systemctl stop cron, sudo systemctl disable cron
  • apt remove cron pode tentar instalar postfix etc.
  • Isso acontece porque o cron sugere um mail transport agent

• /usr/sbin/rsyslogd -n

  • rsyslogd é um utilitário de sistema que dá suporte a message logging
  • É responsável por preencher arquivos de log em /var/log/, como /var/log/auth.log
  • Os arquivos de configuração ficam em /etc/rsyslog.d
  • É possível configurar centralized logging enviando logs para um servidor remoto
  • Com o comando logger, scripts em background podem deixar mensagens em /var/log/syslog
  • Mesmo já havendo systemd-journald, rsyslog e journal têm características diferentes, então pode ser útil usá-los juntos em certos cenários
  • Por isso, foi mantido por enquanto

• /usr/sbin/acpid

  • acpid é o daemon de eventos ACPI
  • Foi projetado para notificar programas em user-space sobre eventos ACPI
  • ACPI é usado para descoberta/configuração de componentes de hardware, gerenciamento de energia, monitoramento de status etc.
  • Como não havia intenção de suspender/retomar em um servidor virtual, foi testada sua remoção
  • reboot funcionou, mas depois de halt a DigitalOcean ainda o reconhecia como ligado, então foi necessário usar Power Off pela interface web
  • Portanto, a conclusão é que é melhor mantê-lo

• /usr/bin/lxcfs /var/lib/lxcfs/

  • lxcfs é um filesystem FUSE projetado para containers LXC
  • Fornece uma visão virtualizada de alguns arquivos em /proc e acesso filtrado ao filesystem cgroup do host
  • Faz com que uptime, top etc. dentro do container tenham resultados mais “corretos”
  • Se você não usa containers LXC, pode removê-lo com sudo apt remove lxcfs -y --purge

• /usr/lib/accountservice/accounts-daemon

  • AccountsService fornece uma interface D-Bus e uma implementação para consultar e manipular informações de contas de usuário
  • A implementação se baseia nos comandos usermod(8), useradd(8), userdel(8)

• O que vai quebrar depois da remoção ficou como “Time will tell”

• /sbin/mdadm

  • mdadm é um utilitário Linux para gerenciar e monitorar software RAID devices
  • RAID é uma forma de usar vários hard drives como se fossem um só
  • RAID 0 expande a capacidade dos drives
  • RAID 1, RAID 5, RAID 6 e RAID 10 têm como objetivo evitar data loss em caso de drive failure
  • Pode ser removido com sudo apt remove mdadm -y --purge

• /usr/lib/policykit-1/polkitd --no-debug

  • polkitd é o daemon do PolicyKit, e polkit é um Authorization Framework
  • Pode ser entendido como uma espécie de sudo com granularidade fina
  • Permite conceder a um usuário sem privilégios o direito de executar ações específicas como root
  • Exemplo: permitir reboot em um desktop Linux
  • Em servidores, foi resumido que pode ser removido com sudo apt remove policykit-1 -y --purge
  • O que vai quebrar ainda permanece como dúvida

• /usr/sbin/sshd -D

  • sshd é o OpenSSH Daemon
  • A opção -D faz com que ele não se desanexe e não vire daemon, facilitando o monitoramento

• /sbin/iscsid

  • iscsid é um daemon em background que opera conforme a configuração de iSCSI e gerencia conexões
  • iSCSI é um padrão de storage networking baseado em IP que transmite comandos SCSI por uma rede IP, permitindo usar storage remoto como se fosse um disco local
  • Pode ser removido com sudo apt remove open-iscsi -y --purge

• /sbin/agetty --noclear tty1 linux

  • agetty é um getty alternativo para Linux
  • getty gerencia terminais físicos ou virtuais e, quando detecta uma conexão, exibe um prompt de nome de usuário e depois executa o programa login
  • Na Digital Ocean, é possível interagir com esse terminal pelo navegador usando Console nos detalhes do droplet
  • Ao remover arquivos relacionados a [e-mail] e reiniciar, o acesso via SSH ainda era possível, mas não dava para fazer login pelo web console da Digital Ocean

• Sessão SSH, bash, htop

  • sshd: root@pts/0 significa que a SSH session do usuário root foi configurada no pseudoterminal pts/0
  • Um pseudoterminal emula um terminal de texto real
  • bash é o shell em uso
  • Quando há um traço no início, como em -bash, ele foi iniciado como login shell
  • Um shell cujo primeiro caractere do argumento zero é -, ou que foi iniciado com a opção --login, é um login shell
  • Nesse caso, ele lê um conjunto diferente de arquivos de configuração
  • htop é o visualizador interativo de processos em execução no screenshot

Experimento de remoção de serviços

• A lista de remoção comum é a seguinte
  • sudo apt remove lvm2 -y --purge
  • sudo apt remove at -y --purge
  • sudo apt remove snapd -y --purge
  • sudo apt remove lxcfs -y --purge
  • sudo apt remove mdadm -y --purge
  • sudo apt remove open-iscsi -y --purge
  • sudo apt remove accountsservice -y --purge
  • sudo apt remove policykit-1 -y --purge
• A edição Extreme inclui as seguintes tarefas
  • sudo apt remove dbus -y --purge
  • sudo apt remove rsyslog -y --purge
  • sudo apt remove acpid -y --purge
  • sudo systemctl stop cron && sudo systemctl disable cron
  • sudo rm /etc/systemd/system/getty.target.wants/[e-mail]
  • sudo rm /lib/systemd/system/getty@.service
• Uma configuração de nginx, PHP7 e MySQL seguindo as instruções de unattended installation of WordPress on Ubuntu Server funciona

Apêndice: ferramentas de investigação e comportamento do shell

• Encontrando o código-fonte

  • Quando apenas strace não é suficiente, é possível consultar o código-fonte
  • Encontre a localização do binário com which uptime e o pacote do Ubuntu com dpkg -S /usr/bin/uptime
  • No exemplo, uptime pertence ao pacote procps
  • Em packages.ubuntu.com, é possível pesquisar o pacote e encontrar o link do repositório de código-fonte

• file descriptor e redirection

  • Para redirecionar stderr para stdout, usa-se 2>&1
  • echo something > file escreve stdout em file e é equivalente a echo something 1> file
  • echo something 2> file escreve stderr em file
  • echo something 2>1 significa redirecionar stderr para um filename chamado 1
  • Em 2>&1, com &, 1 não é um filename, mas sim um stream ID

• Problema de cores no PuTTY

  • Se elementos do htop parecerem ausentes no PuTTY, isso pode ser resolvido nas configurações Window → Colours
  • Clique com o botão direito na title bar
  • Change settings...
  • Window → Colours
  • Selecione Both radio button
  • Apply

• Um shell simples feito em C

  • Um shell simples escrito em C demonstra o uso das chamadas de sistema fork, exec e wait
  • Se a entrada for exit, ele encerra como um built-in do shell
  • Outros comandos são executados com execlp no child após fork, e o parent aguarda o status de término com waitpid
  • Exemplos executando date, true e false mostram o exit code do child, respectivamente
  • A razão pela qual a mensagem de término de um background process como sleep 1 & só aparece depois de pressionar Enter é que o shell fica aguardando input e verifica o status do background process quando um comando é inserido

Itens restantes de investigação e histórico de correções

• Os itens que ainda se deseja investigar incluem process state substatus, kernel thread, /dev/pts, memória CODE·DATA·SWAP, duração do time slice, algoritmo do Linux scheduler, core pinning, manual page, cores das barras de CPU/memory, limite de process ID e fork bomb, lsof, ionice, schedtool etc.
• As principais correções e atualizações incluem o seguinte
  • O idle time de /proc/uptime é a soma de todos os cores
  • Os printf de parent/child no exemplo C de zombie foram corrigidos
  • Foi acrescentado que apt remove cron tenta instalar postfix por causa da dependência de MTA
  • id pode carregar informações de outras fontes além de /etc/passwd por meio de /etc/nsswitch.conf
  • Foi acrescentada a explicação do formato de password hash de /etc/shadow
  • /etc/sudoers deve ser editado com segurança usando visudo
  • Foi acrescentada a explicação de MEM%
  • A seção de load average foi reescrita
  • O signal padrão de kill 1234 foi corrigido de INT para TERM
  • Foi acrescentada a explicação das color bars de CPU e memory

[GN⁺]

Comentários do Hacker News

• Recentemente migrei para o btop; a interface parece moderna e útil na medida certa, com informação suficiente
  Como outras pessoas comentaram, aparentemente também mostra consumo de energia (Watts), além de rede, GPU e disco
  https://github.com/aristocratos/btop

  • O btop é bom, mas também tem desvantagens: não há estatísticas de zram/zswap (o htop também só suporta zram), não há detalhamento das estatísticas do ZFS e ainda não há suporte para GPU Arc
    Não dá para desativar a barra de uso de disco, então, se a janela do console não for bem grande, o gráfico de velocidade de I/O fica bem espremido
  • Uso o btop há bastante tempo, e o que sinto falta é basicamente só de uma coluna de porta ao lado das outras colunas
    Os gráficos de CPU/GPU ocupam espaço demais e, no geral, eu queria que a tabela de arquivos abertos tivesse mais espaço
  • Ainda uso Alpine às vezes como imagem base de contêiner, mas o btop parece não suportar musl, então fica de fora
  • Sou tão fã do btop que, no meu MacBook novo, ele substituiu até o iStatMenu

• Sempre mudo 2 configurações quando uso o htop, e a diferença é grande
  Primeiro, desativo as threads de usuário. Em geral só poluem a tela do htop e quase não trazem informação útil
  Segundo, ativo a visualização em árvore de processos. Muitas vezes é mais importante saber de onde um processo foi iniciado do que outras informações, e também fica mais fácil rastrear coisas como processos de compilador que consomem CPU enquanto processam muitos arquivos
  Pessoalmente, acho que ambos deveriam ser o comportamento padrão do htop

  • A visualização em árvore de processos é boa, mas é uma pena que, quando ela está ativada, a atualização dinâmica e a reordenação da lista de processos parem

• É bom ver uma explicação de por que é difícil confiar na memória virtual. O modo como o Gerenciador de Tarefas do Windows mostra isso por padrão é péssimo
  O resident set size (RSS) é o indicador mais confiável, e os outros valores podem ser inflados de forma enganosa por coisas como arquivos mapeados em memória, que na prática não causam problema
  Por exemplo, mesmo que você mapeie em memória um arquivo de log de 2 GB, ele só será carregado em páginas quando essa parte for lida, então isso não significa uso real de memória, mas o usuário olha para o processo e diz “por que esse app está usando tanta memória?”
  O Chrome também teve esse problema por um tempo e reduziu o uso de arquivos mapeados em memória, não porque arquivos mapeados em memória fossem ruins, mas porque os usuários reagiam exageradamente ao ver um valor que não representava o uso real de memória física
  Também existem guias na web dizendo para avaliar uso de memória pela alocação de memória virtual, mas este texto ao menos acerta nessa parte

  • Na prática, o proportional set size (PSS) é mais preciso que o RSS
    Referência: https://en.wikipedia.org/wiki/Proportional_set_size
  • Se você usar arquivos mapeados em memória, as páginas em cache entram no resident set size desse processo
    Se usar I/O normal de arquivos, não entram. Em clusters HPC que monitoram o uso de memória de cada job e matam o processo se ele passar do solicitado, isso gera resultados bem curiosos
  • O resident set size não é a quantidade de memória que o processo quer, e sim a quantidade que o sistema operacional decidiu dar a ele
    Quando começa a haver pressão de memória, ele deixa de ser representativo. Já vi decisões erradas por causa desse mal-entendido e até removi esse valor de um gráfico para impedir que um colega tirasse a conclusão errada
  • Para ser preciso, o Gerenciador de Tarefas do Windows usa por padrão Private Working Set como valor de uso de memória do processo, e isso não inclui páginas compartilhadas com outros processos, como bibliotecas ou arquivos mapeados em memória
    Como o nome sugere, ele mostra apenas a parte mapeada em memória física alocada privadamente para cada processo, sendo mais próximo do Resident Set no Unix
    Você provavelmente estava falando do uso de memória na aba de desempenho, mas estou fazendo essa distinção porque isso pode ser entendido como se valesse para todos os itens de uso de memória

• No top, usar o caractere > faz a ordenação por uso de memória
  Às vezes uso isso quando estou procurando por que o host ficou lento, e dá para ver até o swapd consumindo CPU

  • Prefiro usar M maiúsculo para memória e P maiúsculo para CPU

• Ler textos assim me faz perceber que, mesmo usando Linux todos os dias há mais de 20 anos, eu ainda só aproveito uma parte do potencial. Ótimo texto

• Parece que o HN está voltando a se recuperar
  Espero que este não seja o período fantasma ambulante do HN

  • Há 3 posts sobre IA na primeira página, mas um deles é um post criticando conteúdo gerado de baixa qualidade, então fico esperançoso
  • Pelo visto a recuperação está acontecendo voltando para posts de antes da era do slop, de 7 anos atrás

• Para quem não conhece o nmon, também vale a pena dar uma olhada
  Se você apertar h, aparece a lista de monitores disponíveis; apertando de novo, ela some, e q sai do programa
  https://nmon.sourceforge.io/pmwiki.php
  Especialmente o throughput de disco e I/O vistos com as teclas d e D são bem úteis

  • Conheci isso nos equipamentos AIX usados no trabalho, e também me lembra o topas
  • É uma ferramenta muito útil, então eu a instalo em todas as máquinas que consigo controlar
    O gráfico largo de uso de CPU lida muito bem com grandes quantidades de núcleos, o que é ótimo

• Em vez da forma de uso dos utilitários da família *top, passei a preferir relatórios diferenciais mais tranquilos no estilo ps e relatórios do sistema inteiro como o vmstat
  Assim, tudo fica preservado no buffer de rolagem do terminal: https://github.com/c-blake/procs
  Foi escrito em Nim, uma linguagem incomumente eficiente e expressiva

• Tenho este texto salvo nos favoritos desde 2016 e voltei a consultá-lo várias vezes ao longo dos anos