Explicación de los valores que aparecen en la pantalla de Linux htop/top (2019)

• Tomando como punto de partida la pantalla de htop en Ubuntu Server 16.04 x64, se rastrea qué significan realmente uptime, load average, Tasks, PID, el árbol de procesos, los estados, el tiempo de CPU, la prioridad y los indicadores de memoria mediante /proc y la salida de comandos
• Muchos de los valores en pantalla provienen de procfs y de archivos del sistema como /etc/passwd, /etc/group, /etc/shadow y /etc/nsswitch.conf, y con strace se puede verificar qué archivos lee un programa
• Load average no es lo mismo que el uso de CPU, sino un promedio móvil con decaimiento exponencial que incluye procesos en ejecución, en espera de ejecución y procesos en estado uninterruptible
• Códigos de estado como R, S, D, Z, T, t están conectados con señales, kill y el comportamiento de fork/exec/wait, por lo que sirven como pista para determinar por qué un proceso se quedó detenido o sigue ahí
• VIRT, RES, SHR, MEM% muestran la memoria virtual, la memoria física y la memoria compartible desde perspectivas distintas, así que es difícil asegurar el uso real de memoria mirando solo un número

---

De dónde vienen los valores de htop

• uptime muestra cuánto tiempo lleva ejecutándose el sistema, y la misma información también puede verse con el comando uptime
• El programa uptime lee /proc/uptime
  • El primer número es el tiempo total, en segundos, que el sistema ha estado encendido
  • El segundo número es el tiempo, en segundos, que el sistema ha estado en estado idle
  • En sistemas multinúcleo, el tiempo idle puede sumarse por núcleo y ser mayor que el uptime total
• Con strace uptime 2>&1 | grep open o strace -e open uptime se pueden ver los archivos que abre uptime
  • En la salida de ejemplo aparecen /proc/uptime, /var/run/utmp y /proc/loadavg
• Los números de /proc/uptime son prácticos para usar en programas o scripts, mientras que la salida de uptime está formateada para que sea fácil de leer por personas

Load average y uso de CPU

• Los tres primeros valores de /proc/loadavg representan el load average del sistema en los últimos 1, 5 y 15 minutos
• El cuarto valor muestra el número de procesos que se están ejecutando actualmente y el número total de procesos en un formato como 1/120, y el último valor es el último PID utilizado
• Al ejecutar un proceso nuevo se le asigna un PID, y normalmente los PID van aumentando hasta que se agotan y luego se reutilizan
  • El PID 1 pertenece a /sbin/init, que se inicia durante el arranque
• Si en htop solo se ve un proceso en ejecución, ese único proceso podría ser el propio htop
• sleep 30 no está en ejecución sino en estado sleep, así que no aumenta la cantidad de running processes
• Un trabajo que usa CPU de forma continua, como cat /dev/urandom > /dev/null, aumenta la cantidad de running processes y el load average
• El load number cuenta los procesos que están ejecutándose o esperando ejecutarse, así como los procesos en estado uninterruptible
• El load average no es un promedio simple, sino un promedio móvil con decaimiento exponencial
  • Incluso el load average de 1 minuto no refleja solo los últimos 60 segundos, sino que da más peso al último minuto e incluye en parte actividad anterior
• En un sistema de una sola CPU, si hay un proceso CPU-bound, puede simplificarse que un load average de 1.00 equivale a un uso de CPU del 100%
  • En un sistema de 2 núcleos, la misma situación puede verse como 50% de uso de CPU
  • En un sistema de 2 núcleos, el load average que puede simplificarse como equivalente a 100% de CPU es 2.00
• Esta simplificación no siempre es correcta porque los procesos en estado uninterruptible también se incluyen en la carga
  • Es posible tener un load average alto aunque el uso de CPU no sea alto
• El uso instantáneo de CPU puede comprobarse con mpstat
  • sudo apt install sysstat -y
  • mpstat 1

Tasks, PID y árbol de procesos

• Tasks en la parte superior derecha de htop muestra el número total de procesos y el número de procesos en ejecución
• Internamente, el kernel de Linux llama task a los procesos, y htop usa Tasks en lugar de Processes para ahorrar espacio en pantalla
• Con Shift+H se puede alternar la visualización de threads
  • Si aparece algo como Tasks: 23, 10 thr, significa que los threads se están mostrando
• Con Shift+K se puede alternar la visualización de kernel threads
  • Si aparece algo como Tasks: 23, 40 kthr, significa que los kernel threads se están mostrando
• Cada vez que se inicia un proceso nuevo se le asigna un PID
  • Si se ejecuta en segundo plano con algo como sleep 1000 &, se muestran el número de job y el PID
  • En bash, $! se expande al ID del último proceso en segundo plano
• La información relacionada con los procesos está bajo /proc/<pid>/
  • /proc/<pid>/cmdline contiene el comando ejecutado, y los argumentos están separados por bytes \0
  • Puede verse de forma más legible con tr '\0' '\n' < /proc/<pid>/cmdline o strings /proc/<pid>/cmdline
  • /proc/<pid>/cwd es un enlace al directorio de trabajo actual, y /proc/<pid>/exe es un enlace al binario ejecutado
• Herramientas de diagnóstico como htop, top y ps leen los detalles de los procesos desde /proc/<pid>/<file>
• El proceso que crea uno nuevo es el parent process, y el recién creado es el child process; esta relación forma el árbol de procesos
• Al pulsar F5 en htop se puede ver la jerarquía de procesos
  • ps f y pstree -a también muestran la misma relación
• Cuando se ejecuta date en bash, bash crea una copia de sí mismo con fork, carga /bin/date en memoria con exec, y luego el bash padre espera a que el child termine
• /sbin/init se inicia durante el arranque y lanza sshd; cuando se establece una conexión SSH, sshd crea el proceso de sesión y esa sesión ejecuta la shell bash

Usuarios y permisos de los procesos

• Cada proceso pertenece a un usuario, y ese usuario se representa con un ID numérico
• Se puede comprobar el ID de usuario de un proceso con el campo Uid de /proc/<pid>/status
• Un comando como id 1000 muestra el nombre de usuario y los grupos correspondientes a ese ID numérico
• id elige la fuente para resolver nombres según la configuración de /etc/nsswitch.conf
  • En el sistema de ejemplo, lee /etc/passwd y /etc/group
  • compat es el modo de compatibilidad; es igual a files, pero permite entradas especiales
  • La información de usuarios también puede almacenarse en otras bases de datos o servicios, como LDAP
• /etc/passwd y /etc/group son archivos de texto plano que mapean IDs numéricos a nombres legibles para humanos
• La información real de las contraseñas está en /etc/shadow
  • $6$ significa el algoritmo de hash sha512
  • Después siguen un salt aleatorio para evitar ataques de rainbow table y el hash de password+salt
• Por defecto, los programas se ejecutan con los permisos del usuario que los lanzó
  • Esto sigue siendo igual aunque el propietario del ejecutable sea otro usuario
• Para ejecutarlos como otro usuario o como root, se usa sudo
  • sudo id se ejecuta con el UID 0 de root
  • Se puede ejecutar como un usuario específico con algo como sudo -u daemon id
• Si intentas escribir directamente en /etc/sudoers con redirección, puede que solo echo se ejecute como root y que el append lo haga el usuario actual, por lo que fallará
  • echo "$USER ALL=(ALL) NOPASSWD: ALL" | sudo tee -a /etc/sudoers
  • sudo bash -c "echo '$USER ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers"
• /etc/sudoers debe editarse con sudo visudo
  • Valida el contenido antes de guardar para evitar errores que dejen sudo inutilizable
• /usr/bin/passwd puede escribir en /etc/shadow aunque lo ejecute un usuario normal
  • Tiene una s en los permisos del archivo, por lo que funciona como ejecutable setuid
  • Se ejecuta con los permisos del propietario del ejecutable, que es root
  • Los ejecutables setuid propiedad de root se pueden encontrar con find /bin -user root -perm -u+s

Códigos de estado de los procesos

• La columna de estado de htop se muestra con el nombre S, y sus valores principales son los siguientes
  • R: running o runnable, en ejecución o esperando en la run queue
  • S: interruptible sleep, esperando a que se complete un evento
  • D: uninterruptible sleep, normalmente esperando I/O
  • Z: defunct zombie, terminó pero el parent no hizo reap
  • T: detenido por una señal de job control
  • t: detenido por el debugger durante tracing
  • X: dead, un estado que no debería aparecer
• ps también muestra subestados como Ss, R+, Ss+

• R: en ejecución o listo para ejecutarse

  • El estado R significa que el proceso se está ejecutando en ese momento o está esperando en la cola de ejecución
  • El código fuente de un programa, tras compilarse, se convierte en instrucciones de CPU, y al ejecutarse se carga en memoria para que la CPU ejecute esas instrucciones
  • Estar en ejecución significa que la CPU está ejecutando físicamente instrucciones

• S: sleep interrumpible

  • En el estado S, las instrucciones del proceso no se ejecutan en la CPU, sino que esperan un evento o condición
  • Cuando ocurre el evento, el kernel cambia el estado a running
  • sleep 1000 es un ejemplo de espera durante un tiempo determinado
  • Este estado puede interrumpirse con una signal
  • En htop, se puede enviar una signal presionando F9
  • kill es la system call que envía una signal, y /bin/kill es el programa en userland que la invoca
  • La signal predeterminada es TERM y solicita la finalización del proceso
  • Las signals son numéricas; sus nombres suelen escribirse en mayúsculas y pueden llevar el prefijo SIG
  • Ej.: INT, KILL, STOP, CONT, HUP
  • kill -INT 10089, kill -2 10089, /bin/kill -2 10089 hacen lo mismo
  • Al presionar CTRL+C, bash envía SIGINT al proceso en foreground
  • Enviar SIGINT o SIGTERM no garantiza que el proceso termine
  • Un programa puede configurar un signal handler para hacer tareas de limpieza y luego salir
  • SIGKILL o 9 hace que el kernel fuerce la terminación del proceso sin darle oportunidad de responder

• D: sleep ininterrumpible

  • El estado D no puede despertarse con signals, y como SIGKILL también es una signal, no se puede matar ese tipo de procesos
  • Este estado se usa cuando un proceso debe esperar sin interrupción o cuando se espera que el evento ocurra rápidamente
  • Ej.: lectura/escritura en disco
  • Un proceso ininterrumpible suele estar esperando I/O después de un page fault
  • Este estado puede aparecer con demoras en lectura o escritura sobre NFS
  • También puede aparecer cuando hay muy poca memoria disponible y el proceso hace mucho swap
  • Como ejemplo, si ejecutas sudo mount 8.8.8.8:/tmp /tmp &, /sbin/mount.nfs quedará en estado D
  • Si lo miras con strace, verás que la system call mount bloquea el proceso
  • Si se usa la opción intr en mount, puede ejecutarse de forma interrumpible
  • sudo mount 8.8.8.8:/tmp /tmp -o intr

• Z: procesos zombie

  • El estado Z significa que el proceso terminó pero el parent todavía no hizo reap
  • Un proceso zombie puede ser normal si existe solo por poco tiempo
  • Un proceso zombie que permanece mucho tiempo puede indicar un bug en el programa
  • Los procesos zombie no consumen memoria; solo ocupan un PID
  • No se puede hacer kill directamente a un proceso zombie
  • Se puede enviar SIGCHLD al proceso parent para pedirle que haga reap del zombie
  • Si se mata al proceso parent, se puede eliminar al parent y a sus zombies
  • Se puede reproducir el estado zombie con un programa en C donde, tras fork, el child hace exit(0) y el parent hace sleep(20)
  • Cuando termina el parent, el zombie desaparece
  • Los zombies se mantienen porque el parent necesita poder revisar el código de salida del child con la system call wait

• T y t: procesos detenidos

  • El estado T indica que el proceso está detenido por una señal de job control
  • Si ejecutas cat /dev/urandom > /dev/null y presionas CTRL+Z, pasará al estado T
  • Puedes reanudarlo con fg
  • También se puede detener con la signal STOP y reanudar con la signal CONT
  • El estado t indica que está detenido mientras un debugger lo está trazando
  • Si haces attach a un proceso ejecutado con nc -l 1234 & usando sudo gdb -p <pid>, quedará en estado t

Tiempo de CPU, niceness y prioridad

• Linux es un sistema operativo multitarea, así que incluso en una sola CPU parece que varios procesos se ejecutan al mismo tiempo
• En realidad, una sola CPU solo puede ejecutar una instrucción a la vez, por lo que usa time sharing
  • Un proceso se ejecuta brevemente y luego se interrumpe
  • Otros procesos en espera de ejecución se van ejecutando por turno
  • Al breve intervalo en que se ejecuta un proceso se le llama time slice
• Un time slice suele durar unos pocos milisegundos, así que si la carga del sistema no es alta normalmente no se percibe
• En un solo núcleo, si el load average es 1.0, puede considerarse que la CPU está usada al 100%
  • Si es mayor que 1.0, puede haber más procesos queriendo ejecutarse de los que la CPU puede manejar, lo que puede causar ralentización o demoras
  • Si es menor que 1.0, la CPU queda en estado idle algunas veces
• La razón por la que el running time de un proceso puede no coincidir exactamente con el tiempo transcurrido real también se explica por el time sharing
• Si hay más tareas para ejecutar que núcleos de CPU disponibles, hay que decidir qué tarea ejecutar primero
• El scheduler del kernel de Linux elige el siguiente proceso desde la run queue, según el algoritmo de planificación del kernel
• En general no se puede controlar directamente el scheduler, pero sí se le puede indicar qué procesos son más importantes
• niceness, mostrado como NI, es la prioridad en user-space
  • Su rango va de -20 a 19
  • -20 es la prioridad más alta y 19 la más baja
  • Puede verse como que un proceso más nice cede más a otros menos nice
• PRI es la prioridad en kernel-space que usa el kernel de Linux
  • Su rango va de 0 a 139
  • 0~99 es para real time y 100~139 es el rango para usuario
• La relación entre el valor nice y la prioridad se explica con PR = 20 + NI
  • El rango -20~+19 de NI se convierte en 0~39 de PR, y eso se mapea a 100~139
• Antes de ejecutar, la niceness se configura con nice -n niceness program
• La niceness de un proceso en ejecución se cambia con renice -n niceness -p PID
• Los colores del uso de CPU son los siguientes
  • Blue: hilo de baja prioridad, nice > 0
  • Green: hilo con prioridad normal
  • Red: hilo del kernel

Métricas de memoria: VIRT, RES, SHR, MEM%

• Un proceso parece existir de manera independiente en memoria, y esto se implementa mediante memoria virtual
• Un proceso no accede directamente a la memoria física, sino que tiene su propio virtual address space
• El kernel puede traducir direcciones de memoria virtual a memoria física, o mapear parte de ella al disco
• Por eso puede parecer que un proceso usa más memoria que la que tiene instalada la computadora
• El uso de memoria de un proceso varía según si incluye los siguientes elementos
  • biblioteca compartida
  • memoria mapeada a disco
  • memoria intercambiada a swap
• Los colores del uso de memoria son los siguientes
  • Green: memoria usada
  • Blue: buffers
  • Orange: cache

• VIRT/VSZ

  • VIRT es la cantidad total de memoria virtual que usa la tarea
  • Incluye código, datos, bibliotecas compartidas, páginas enviadas a swap y páginas mapeadas pero no usadas
  • Aunque una aplicación pida 1 GB y solo use 1 MB, VIRT puede aparecer como 1 GB
  • Aunque se haga mmap de un archivo de 1 GB y no se use realmente, VIRT puede mostrarse como 1 GB
  • En la mayoría de los casos, VIRT no es una cifra útil

• RES/RSS

  • RES es la memoria física no enviada a swap, es decir, el uso de memoria residente que está actualmente en memoria física
  • RES puede reflejar mejor el uso real de memoria que VIRT, pero tiene limitaciones
  • No incluye la memoria enviada a swap
  • Parte de la memoria puede compartirse con otros procesos
  • Si un proceso usa 1 GB de memoria y luego hace fork(), el RES de ambos procesos puede verse como 1 GB cada uno, pero en realidad Linux puede estar usando solo 1 GB gracias a copy-on-write

• SHR

  • SHR es la cantidad de memoria compartida que usa la tarea
  • Refleja la memoria que potencialmente puede compartirse con otros procesos
  • El programa de ejemplo en C muestra cómo cambian los valores VIRT, RES y SHR al pasar por malloc, usar parte de la memoria, fork y escribir memoria adicional
  • La sección de ejemplo de memoria correspondiente sigue pendiente como TODO

• MEM%

  • MEM% es el porcentaje de memoria física disponible que la tarea está usando actualmente
  • Es el valor de RES dividido entre la RAM total
  • Ejemplo: si RES es 400M y la RAM es de 8 GB, entonces 400/8192*100 = 4.88%

Procesos predeterminados de Ubuntu Server 16.04

• Se investigaron los procesos que se inician en un Ubuntu Server 16.04.1 LTS x64 de un droplet nuevo de Digital Ocean.

• /sbin/init

  • /sbin/init coordina el resto del boot process y configura el entorno de usuario.
  • Se convierte en el parent o grandparent de los procesos que se inician automáticamente.
  • El resultado de dpkg -S /sbin/init es systemd-sysv: /sbin/init, así que en ese sistema es systemd.
  • Aunque se mate el proceso, no pasa nada.

• /lib/systemd/systemd-journald

  • systemd-journald es un servicio del sistema que recopila y almacena logging data.
  • Crea y mantiene un journal estructurado e indexado con base en la información de logs recibida de varias sources.
  • Usa un formato de archivo especial optimizado para mensajes de log en lugar de archivos de log simples en texto plano.
  • Se consulta con 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 que no se puede eliminar ni desactivar, y solo se puede apagar el logging.

• /sbin/lvmetad -f

  • lvmetad hace cache de los metadatos de LVM para que los comandos de LVM lean esos metadatos sin hacer disk scan.
  • El disk scan toma tiempo y puede interferir con el trabajo normal del sistema y del disco.
  • LVM puede verse como “particiones dinámicas” con las que Linux puede crear, redimensionar y eliminar logical volumes mientras está en ejecución.
  • La conclusión es que conviene mantenerlo si se está usando LVM.

• /lib/systemd/udevd

  • systemd-udevd escucha los uevent del kernel y ejecuta, para cada evento, las instrucciones de coincidencia de las udev rules.
  • udev es el device manager del kernel de Linux y administra principalmente los device nodes del directorio /dev.
  • No hay certeza de si es necesario en un servidor virtual.

• /lib/systemd/timesyncd

  • systemd-timesyncd es un servicio del sistema que sincroniza el reloj local con servidores NTP remotos.
  • Reemplaza a ntpd.
  • En el sistema de ejemplo, timedatectl status muestra yes tanto para network time como para NTP synchronized.
  • En la salida de netstat solo aparece el puerto SSH en estado listening, y no abre varios puertos UDP 123 como ntpd en Ubuntu 14.04.

• /usr/sbin/atd -f

  • atd ejecuta los jobs que se ponen en cola para correr después.
  • at y batch leen comandos desde stdin o desde un archivo para ejecutarlos más tarde.
  • A diferencia de cron, que programa ejecuciones repetidas, at ejecuta una sola vez a una hora específica.
  • En el ejemplo, echo "touch /tmp/yolo.txt" | at now + 1 minute crea un archivo un minuto después.
  • Si no se usa, se elimina con sudo apt remove at -y --purge.

• /usr/lib/snapd/snapd

  • Snappy Ubuntu Core se presenta como una edición de Ubuntu que usa transactional update.
  • Se describe a snap como un formato universal de paquetes de Linux que permite que un solo binary package funcione en desktop, server, cloud y device de Linux.
  • Puede entenderse como un paquete deb simplificado que distribuye las dependencias agrupadas dentro de un solo snap.
  • Como no se ha usado snappy para deployar o distribuir aplicaciones en el servidor, se elimina con sudo apt remove snapd -y --purge.

• /usr/bin/dbus-daemon

  • D-Bus es un mechanism de IPC y RPC entre varios process que se ejecutan al mismo tiempo en la misma machine.
  • Es necesario en un desktop environment, pero se duda de si hace falta en un server que ejecuta una web app.
  • Al eliminar dbus, timedatectl status falla con Failed to create bus connection: No such file or directory.
  • Por eso, la conclusión es que conviene mantenerlo.

• /lib/systemd/systemd-logind

  • systemd-logind es un servicio del sistema que administra los inicios de sesión de usuario.

• /usr/sbin/cron -f

  • cron es un daemon que ejecuta comandos programados.
  • -f significa que no se daemoniza y se ejecuta en foreground mode.
  • Las tareas que se ejecutan de forma periódica pueden programarse con cron.
  • crontab -e
  • La conclusión es que en Ubuntu se suele usar /etc/cron.hourly, /etc/cron.daily, etc.
  • Los logs pueden verse de la siguiente manera.
  • grep cron /var/log/syslog
  • journalctl _COMM=cron
  • journalctl _COMM=cron --since="date" --until="date"
  • Es muy probable que cron se mantenga.
  • Si no se va a eliminar, puede detenerse y desactivarse con sudo systemctl stop cron, sudo systemctl disable cron.
  • apt remove cron puede intentar instalar postfix y otros paquetes.
  • Esto se debe a que cron sugiere un mail transport agent.

• /usr/sbin/rsyslogd -n

  • rsyslogd es una utilidad del sistema que soporta message logging.
  • Se encarga de llenar archivos de log en /var/log/, como /var/log/auth.log.
  • Los archivos de configuración están en /etc/rsyslog.d.
  • Se puede armar logging centralizado enviando logs a un servidor remoto.
  • Con el comando logger se pueden dejar mensajes en /var/log/syslog desde un background script.
  • Aunque ya exista systemd-journald, rsyslog y journal tienen características distintas, así que puede ser útil usarlos juntos.
  • Por eso se mantiene por ahora.

• /usr/sbin/acpid

  • acpid es un daemon de eventos ACPI.
  • Está diseñado para notificar eventos ACPI a programas en user space.
  • ACPI se usa para descubrimiento y configuración de componentes de hardware, power management, monitoreo de estado y más.
  • Como no se pretende usar suspend/resume en un servidor virtual, se probó eliminarlo.
  • reboot funcionó, pero después de halt, Digital Ocean seguía detectando la instancia como encendida, así que hubo que hacer Power Off desde la interfaz web.
  • Por lo tanto, la conclusión es que conviene mantenerlo.

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

  • lxcfs es un filesystem FUSE diseñado para contenedores LXC.
  • Proporciona una vista virtualizada de algunos archivos de /proc y acceso filtrado al filesystem cgroup del host.
  • Hace que uptime, top y otros comandos den resultados más “correctos” dentro del contenedor.
  • Si no se usan contenedores LXC, puede eliminarse con sudo apt remove lxcfs -y --purge.

• /usr/lib/accountservice/accounts-daemon

  • AccountsService proporciona una interfaz D-Bus y su implementación para consultar y manipular información de cuentas de usuario.
  • La implementación se basa en los comandos usermod(8), useradd(8) y userdel(8).

• Tras eliminarlo, se deja en “Time will tell” qué cosas se romperán

• /sbin/mdadm

  • mdadm es una utilidad de Linux para administrar y monitorear dispositivos RAID por software
  • RAID es una forma de usar varios discos duros como si fueran uno solo
  • RAID 0 amplía la capacidad de las unidades
  • RAID 1, RAID 5, RAID 6 y RAID 10 tienen como objetivo evitar la pérdida de datos en caso de falla de una unidad
  • Se puede eliminar con sudo apt remove mdadm -y --purge

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

  • polkitd es el daemon de PolicyKit, y polkit es un framework de autorización
  • Se puede entender como un sudo de grano fino
  • Puede dar a un usuario sin privilegios permiso para realizar ciertas acciones como root
  • Ejemplo: permitir reiniciar en Linux de escritorio
  • Se resume que en un servidor puede eliminarse con sudo apt remove policykit-1 -y --purge
  • Qué cosas se rompen sigue siendo una duda

• /usr/sbin/sshd -D

  • sshd es el daemon de OpenSSH
  • La opción -D hace que no se desacople ni se convierta en daemon, lo que facilita el monitoreo

• /sbin/iscsid

  • iscsid es un daemon en segundo plano que funciona según la configuración de iSCSI y administra las conexiones
  • iSCSI es un estándar de redes de almacenamiento basado en IP que permite transmitir comandos SCSI por una red IP para usar almacenamiento remoto como si fuera un disco local
  • Se puede eliminar con sudo apt remove open-iscsi -y --purge

• /sbin/agetty --noclear tty1 linux

  • agetty es una alternativa de getty para Linux
  • getty administra terminales físicas o virtuales y, cuando detecta una conexión, muestra el prompt de nombre de usuario y luego ejecuta el programa login
  • En Digital Ocean se puede interactuar con esta terminal desde el navegador a través de Console en los detalles del droplet
  • Tras eliminar los archivos relacionados con [e-mail] y reiniciar, era posible conectarse por SSH, pero no iniciar sesión desde la consola web de Digital Ocean

• Sesión SSH, bash, htop

  • sshd: root@pts/0 significa que la sesión SSH del usuario root fue establecida en el pseudoterminal pts/0
  • Un pseudoterminal emula un terminal de texto real
  • bash es el shell en uso
  • Si lleva un guion al inicio, como -bash, significa que se inició como login shell
  • Un shell cuyo primer carácter de argument zero es -, o que se inicia con la opción --login, es un login shell
  • En ese caso lee un conjunto distinto de archivos de configuración
  • htop es el visor interactivo de procesos que se está ejecutando en la captura de pantalla

Experimento de eliminación de servicios

• La lista de eliminación general es la siguiente
  • 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
• La edición Extreme incluye las siguientes tareas
  • 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
• La configuración de nginx, PHP7 y MySQL siguiendo las instrucciones de unattended installation of WordPress on Ubuntu Server funciona

Apéndice: herramientas de investigación y comportamiento del shell

• Buscar código fuente

  • Cuando strace por sí solo no es suficiente, se puede revisar el código fuente
  • Se busca la ubicación del binario con which uptime y el paquete de Ubuntu con dpkg -S /usr/bin/uptime
  • En el ejemplo, uptime pertenece al paquete procps
  • En packages.ubuntu.com se puede buscar el paquete y encontrar el enlace al repositorio del código fuente

• Descriptores de archivo y redirección

  • Para redirigir stderr a stdout se usa 2>&1
  • echo something > file escribe stdout en el archivo, y es lo mismo que echo something 1> file
  • echo something 2> file escribe stderr en el archivo
  • echo something 2>1 significa redirigir stderr a un archivo llamado 1
  • En 2>&1, donde se agrega &, el 1 no es un nombre de archivo sino un ID de flujo

• Problema de colores en PuTTY

  • Si faltan elementos de htop en PuTTY, se puede resolver en la configuración Window → Colours
  • Clic derecho en la barra de título
  • Change settings...
  • Window → Colours
  • Seleccionar el botón de opción Both
  • Apply

• Shell simple hecho en C

  • Un shell simple escrito en C muestra el uso de las llamadas al sistema fork, exec y wait
  • Si la entrada es exit, termina como built-in del shell
  • Los demás comandos se ejecutan con execlp en el child después de fork, y el parent espera el estado de salida con waitpid
  • En los ejemplos de ejecución de date, true y false, se imprime el código de salida del child en cada caso
  • La razón por la que el mensaje de finalización de un proceso en background como sleep 1 & solo aparece después de presionar Enter es que el shell se queda esperando entrada y verifica el estado del proceso en background cuando se introduce un comando

Elementos pendientes de investigar e historial de cambios

• Los temas que quedan por investigar incluyen process state substatus, kernel thread, /dev/pts, memoria CODE·DATA·SWAP, duración del time slice, algoritmos del scheduler de Linux, core pinning, manual page, colores de las barras de CPU/memoria, límite de process ID y fork bomb, lsof, ionice, schedtool, entre otros
• Las principales correcciones y actualizaciones incluyen lo siguiente
  • El idle time de /proc/uptime es la suma de todos los cores
  • Se corrigieron los printf de parent/child en el ejemplo de zombie en C
  • Se agregó que apt remove cron intenta instalar postfix por la dependencia con MTA
  • id puede cargar información también desde otras fuentes además de /etc/passwd a través de /etc/nsswitch.conf
  • Se agregó la explicación del formato de hash de contraseña de /etc/shadow
  • /etc/sudoers debe editarse de forma segura con visudo
  • Se agregó la explicación de MEM%
  • La sección sobre load average fue reescrita
  • Se corrigió que la señal predeterminada de kill 1234 no es INT, sino TERM
  • Se agregó la explicación de las barras de color de CPU y memoria

[GN⁺]

Opiniones en Hacker News

• Últimamente me cambié a btop y la interfaz me pareció lo suficientemente moderna y útil, con una cantidad de información más que suficiente
  Como dijeron otros, parece que también muestra consumo eléctrico (Watts), además de red, GPU y disco
  https://github.com/aristocratos/btop

  • btop está bueno, pero también tiene desventajas: no tiene estadísticas de zram/zswap (htop solo soporta zram), no desglosa en detalle las estadísticas de ZFS y todavía no soporta Arc GPU
    No se puede desactivar la barra de uso de disco, así que si la consola no es bastante grande, el gráfico de velocidad de I/O se ve muy aplastado
  • Llevo mucho tiempo usando btop y lo único que le falta es algo como una columna de puertos junto a las demás columnas
    Los gráficos de CPU/GPU ocupan demasiado espacio y, en general, me gustaría que la tabla de archivos abiertos tuviera más lugar
  • Todavía uso Alpine de vez en cuando como imagen base de contenedores, pero btop queda descartado porque parece que no soporta musl
  • Soy tan fan de btop que hasta reemplazó a iStatMenu en mi MacBook nueva

• Hay 2 configuraciones que siempre cambio al usar htop, y la diferencia es grande
  Primero, desactivo los hilos de usuario. Normalmente solo llenan de ruido la pantalla de htop y casi no aportan información útil
  Segundo, activo la vista de árbol de procesos. Muchas veces es más importante saber de dónde salió un proceso que cualquier otro dato, y también se vuelve más fácil seguir cosas como procesos de compilador que consumen CPU mientras manejan muchos archivos
  Personalmente, creo que ambas deberían ser el comportamiento por defecto de htop

  • La vista de árbol de procesos está buena, pero cuando la activas se detiene la actualización dinámica y reordenación de la lista de procesos, y eso es una lástima

• Da gusto ver una explicación que deja claro que no se puede confiar fácilmente en la memoria virtual. La forma en que el Administrador de tareas de Windows la muestra por defecto va en esa línea y es bastante mala
  El tamaño del conjunto residente (RSS) es el indicador más confiable, y otros valores pueden inflarse erróneamente por cosas como archivos mapeados en memoria que en realidad no causan un problema
  Por ejemplo, aunque mapees en memoria un archivo de logs de 2 GB, esas páginas solo se cargan cuando lees esa parte, así que no significa que realmente estés usando esa memoria; pero el usuario ve el proceso y dice: “¿por qué esta app está usando tanta memoria?”
  Chrome también tuvo este problema durante un tiempo y redujo el uso de archivos mapeados en memoria, no porque fueran malos, sino porque los usuarios reaccionaban de más al ver cifras que no representaban el uso real de memoria física
  En la web hasta hay guías que dicen que hay que juzgar el uso de memoria por la cantidad de memoria virtual asignada, pero este artículo al menos acierta en ese punto

  • En realidad, el tamaño proporcional del conjunto residente (PSS) es más preciso que RSS
    Referencia: https://en.wikipedia.org/wiki/Proportional_set_size
  • Si usas archivos mapeados en memoria, las páginas cacheadas se incluyen en el tamaño del conjunto residente de ese proceso
    Si usas I/O normal de archivos, no se incluyen. En clústeres HPC donde vigilan el uso de memoria de cada trabajo y lo matan si supera el límite solicitado, esto produce resultados bastante curiosos
  • El tamaño del conjunto residente no es la cantidad de memoria que el proceso quiere, sino la cantidad que el sistema operativo decidió darle
    Cuando empieza la presión de memoria, deja de ser representativo. He visto malas decisiones por este malentendido, e incluso una vez quité este valor de un gráfico para evitar que alguien del equipo sacara la conclusión equivocada
  • Para ser precisos, el Administrador de tareas de Windows usa por defecto Private Working Set como valor de memoria de proceso, y no incluye páginas compartidas con otros procesos, como bibliotecas o archivos mapeados en memoria
    Como dice el nombre, solo muestra la parte mapeada a memoria física asignada de forma privada a ese proceso, y se parece más al Resident Set de Unix
    Probablemente se referían al uso de memoria en la pestaña de rendimiento, pero lo aclaro porque se puede malinterpretar como si aplicara a todas las métricas de uso de memoria

• En top, si usas el carácter >, se ordena por uso de memoria
  A veces lo uso cuando trato de encontrar por qué un host se está poniendo lento, y también se puede ver a swapd comiéndose la CPU

  • Prefiero usar M mayúscula para memoria y P mayúscula para CPU

• Leer cosas así me hace darme cuenta de que, incluso después de usar Linux a diario por más de 20 años, todavía solo estoy aprovechando una parte de su potencial. Buen artículo

• Siento que HN se está recuperando otra vez
  Ojalá esto signifique que no era la etapa fantasma ambulante de HN

  • Hay 3 publicaciones sobre IA en la portada, pero una es una crítica a productos generados de baja calidad, así que me da algo de esperanza
  • Supongo que se está recuperando volviendo a publicaciones de hace 7 años, de antes del slop

• Si alguien no conoce nmon, también vale la pena echarle un vistazo
  Si presionas h, aparece la lista de monitores disponibles; si lo vuelves a presionar, desaparece, y con q sales
  https://nmon.sourceforge.io/pmwiki.php
  En especial, el rendimiento de disco e I/O que se ve con las teclas d y D es bastante útil

  • Lo conocí en los equipos AIX que usamos en el trabajo, y también me hace pensar en topas
  • Es una herramienta muy útil, así que la instalo en todas las máquinas que controlo
    Me gusta que el gráfico ancho de uso de CPU maneja fácilmente equipos con muchos núcleos

• Como forma de uso distinta a la familia *top, terminé prefiriendo el reporte diferencial, más calmado, estilo ps, junto con reportes de sistema completo como vmstat
  Así todo queda en el buffer de scrollback de la terminal: https://github.com/c-blake/procs
  Está escrito en el poco común pero eficiente y expresivo lenguaje Nim

• Tengo este artículo guardado en marcadores desde 2016 y lo he vuelto a consultar varias veces a lo largo de los años