ps aux escrito en Bash sin fork

• izabera/ps es una implementación en Bash pensada para imitar, dentro de Bash, una salida cercana a ps aux incluso en situaciones donde no se pueden crear procesos nuevos
• La condición clave es una situación en la que estás conectado por ssh a una máquina y tienes una bash shell de confianza, pero no puedes crear procesos nuevos porque todos los demás PID están en uso
• El README presenta esta situación como ejemplo de pregunta de entrevista para puestos que requieren conocimientos de Bash/Linux
• La herramienta se describe como algo que permite “hacer de cuenta, más o menos” que tienes acceso a un ps aux funcional, y no garantiza ser una implementación de reemplazo completa
• La frase “funciona al 100% en todas las máquinas y en todas las situaciones” se usa claramente como una garantía en tono de broma

---

Qué hace este proyecto

• Es un proyecto que implementa ps aux solo con Bash
• El título del README es “ps aux written entirely in bash without ever forking”
• La característica central del proyecto es que no realiza ningún fork durante su ejecución

Situación prevista

• El escenario de ejemplo es el siguiente
  • Estás conectado a una máquina por ssh
  • El usuario está dentro de una bash shell familiar
  • Pero no puede crear ningún proceso nuevo porque todos los demás PID están en uso
• El README explica que, bajo estas condiciones, podría hacer falta algo parecido a ps aux

Alcance esperable y advertencias

• La herramienta se presenta como algo que permite “kinda sorta pretend” que tienes un ps aux funcional
• La frase del README sobre “funcionar perfectamente en el 100% de las máquinas y en todas las situaciones, garantizado” está escrita como humor exagerado
• Por lo tanto, el punto central de la descripción no es la compatibilidad completa, sino imitar ps aux usando solo Bash en un entorno extremo donde no se pueden crear procesos nuevos

[GN⁺]

Comentarios de Hacker News

• Me identificó el chiste de que el problema más difícil en ciencias de la computación al final era alinear columnas
  He escrito funciones de alineación de columnas incontables veces en varios lenguajes y siempre fue doloroso; en la cabeza parece algo simple, como “calcular la longitud máxima de cada columna y agregar espacios hasta el siguiente múltiplo del tamaño del tabulador”
  Incluso usando f-strings y padding en Python, el código se complica rápido y se vuelve difícil de leer; de hecho, mientras reescribía un ejemplo para un comentario, terminé corrigiendo varios bugs de lo terrible que era

  • Incluso he llegado a agregar Pandas a un proyecto solo para no tener que escribir yo mismo código así para imprimir tablas bonitas
    Para un uso tan común, parecería obvio que existiera una librería, y sinceramente sorprende que no esté en la biblioteca estándar
  • https://perldoc.perl.org/perlform
  • Una vez respondí en Stack Overflow con una solución O(n): https://stackoverflow.com/questions/10865483/print-results-i...
    La idea era sacar el ancho y nombre de las columnas desde description del cursor de base de datos, construir las líneas divisorias y la cadena de formato, y luego imprimir las filas; no sé si se me escapó algún bug fatal, pero no me parece un problema particularmente difícil
  • Más simple todavía: se puede invertir la tabla con zip(*table), calcular la longitud máxima de cada columna y luego imprimir alineado con f"{r:<{w}}"
    El resultado de ejemplo queda como una tabla con anchos de columna alineados, tipo agony | kick | pump
  • Desde la perspectiva opuesta, para quienes tienen que parsear datos alineados por columnas seguido, esto tampoco es nada fácil
    Los valores contienen espacios, están rellenados con espacios y a veces la alineación se rompe o se desborda de la columna
    Mejor ponerse de acuerdo y no usar datos alineados por columnas, sino algún formato más simple y legible para humanos; sería mejor para todos

• Si entré por SSH a una máquina, el shell de Bash sigue vivo pero ya se agotaron todos los PID y no se pueden crear procesos nuevos, me pondría a revisar el sistema de archivos /proc/[pid]/ para identificar qué proceso está agotando el espacio de PID
  kill en Bash es un builtin del shell, así que no hace falta hacer fork de un proceso nuevo como con /bin/kill
  Si se puede encontrar el proceso padre que está generando hijos y agotando los PID, se lo puede detener y recuperar el control del sistema
  Este script también parsea /proc y, como no usa pipes ni sustituciones $(...) que creen subshells nuevos de Bash, queda bastante limpio

  • En una entrevista respondí: “exec Python”
    Así podía invocar las funciones POSIX necesarias sin ejecutar un comando separado, y la reacción fue buena
  • Si soy sincero, yo probablemente solo reiniciaría
    Puede ser más rápido reiniciar y recuperar después que intentar encontrar y matar el proceso padre en un entorno limitado; además, si ya se acabaron los PID, probablemente otras cosas también estén mal
  • Si solo quieres ver PID y nombre del comando, casi en su forma mínima también se puede hacer así: ps(){ (cd /proc;for i in [0-9]*;do echo $i: $(tr '\0' ' ' < $i/cmdline);done); }
  • Tiene sentido querer ver en /proc/[pid]/ qué proceso está agotando el espacio de PID, pero según los comentarios del código fuente, al principio esperaban que con /proc/*/status bastara, aunque ahí no se podían obtener valores como el uso de CPU
  • En lo de los subprocesos, de verdad me intriga cómo funcionan [[ $cmdline ]] && exec {cmdline}>&- y exec {cmdline}< "$dir"/cmdline || continue

• En 2011 tuve una entrevista para un puesto de SRE en una empresa tecnológica bastante grande de EE. UU., y en ese momento ni siquiera había escuchado el término SRE
  La empresa estaba construyendo una alternativa a MS Office basada en navegador y, después de una llamada de filtro, tuve que programar en tiempo real mientras hablaba con el entrevistador dentro del editor de documentos de la propia empresa
  Como en mi autoevaluación había puesto alto shell scripting y Linux, me dieron el ejercicio de hacer un reemplazo de netstat en Bash, pero en ese momento no sabía dónde ni cómo estaba la información de sockets dentro de /proc/, así que decidí rápido que no iba a poder
  En cambio propuse hacer una versión reducida de ps y fuser, y la solución que entregué dentro de ese horroroso procesador de texto en el navegador fue aceptada, así que llegué hasta la entrevista presencial
  Viéndolo ahora, quizá el escenario hipotético que motivó este ejercicio estaba más basado en la realidad de lo que parecía

  • Es probable que algunas de estas utilidades del sistema de todos modos estén mirando internamente procfs/sysfs
    Yo también empezaría por ahí

• Hace tiempo hice por diversión un sitio web interactivo para explorar la situación de estar conectado por SSH sin poder crear procesos nuevos: https://oops.cmdchallenge.com

  • "echo *" no enumera todos los archivos del directorio
    Hay que usar "echo .* *"
  • Está genial, pero cuando lo terminé me devolvió al primer nivel y no pude ver los demás, lo cual fue frustrante
    Me habría gustado revisar la lista de "View Solutions" de otros niveles para ver qué otros enfoques eran posibles

• Izabera es una de las personas más cracks de #bash@libera
  Desde la época de freenode he aprendido muchísimo de gente así durante los últimos 10 años

• Esto es un Bash bastante limpio
  Por experiencia, el código Bash suele estar mal escrito y ser ineficiente, pero este parece un buen ejemplo de que no siempre es así

  • Si va a ser Bash limpio, también debería ser portable, y este script es solo para Linux; en otros lugares se rompería feo

• ¿Qué se hace si estás dentro de un shell POSIX confiable pero sin soporte de Bash?
  Este script de Bash no es compatible con POSIX

• Este script no funciona en Bash 3.2, pero sí en Bash 4.2
  En Bash 3.2 aparece el error printf: '(': invalid format character, y el entorno de ejemplo es bash-3.2-33.el5_11.4.0.1

  • Me parece totalmente razonable no dar soporte a una rama de Bash de hace 18 años y a una rama de sistema operativo de hace 17 años

• Un uso mejor podría ser ver la lista de procesos en un sistema sin procps instalado
  Está bastante bien

• También se pueden hacer listeners y clientes en Bash
  No lo recomendaría en producción