Witr - herramienta que explica por qué un proceso está en ejecución en sistemas Linux

 (github.com/pranshuparmar)
38 puntos por GN⁺ 2025-12-27 | 1 comentarios | Compartir por WhatsApp
  • Witr (why-is-this-running) es una herramienta que muestra con claridad por qué se está ejecutando un proceso, servicio o puerto específico en sistemas Linux
  • A diferencia de ps, top, lsof y otras herramientas existentes, que solo muestran “qué está en ejecución”, presenta en una sola pantalla la relación causal de “por qué está en ejecución”
  • Mediante análisis basado en PID, rastrea el origen del proceso, la ruta de ejecución, la razón por la que se mantiene activo y el contexto al que pertenece
  • Explica la causa de ejecución al integrarse con diversas fuentes como systemd, docker, pm2, cron y shell, y funciona de forma de solo lectura y no destructiva
  • Es una herramienta que reduce el tiempo de comprensión durante la depuración y la respuesta a incidentes, y permite entender de un vistazo la estructura de ejecución de sistemas complejos

Propósito y concepto

  • La pregunta central de Witr es: “¿Por qué se está ejecutando esto? (why-is-this-running)”
    • Rastrea el origen y la causa de todos los elementos en ejecución, como procesos, servicios y puertos
    • Muestra explícitamente las causas indirectas de ejecución a través de varias capas (supervisor, contenedor, servicio, shell, etc.)
  • Mientras que las herramientas existentes solo ofrecen estado y metadatos, Witr expresa claramente las relaciones causales
  • Como resultado, genera una salida fácil de leer para humanos que muestra “qué, cómo, por qué y en qué contexto está en ejecución”

Objetivos principales

  • Explicar la razón de existencia de un proceso y ofrecer información que va más allá de si simplemente está ejecutándose
  • Reducir el tiempo de depuración y respuesta a incidentes
  • Se puede usar de inmediato sin configuración, con garantía de solo lectura y seguridad
  • Prioriza la claridad por encima de la exhaustividad
  • No incluye funciones de monitoreo, análisis de rendimiento ni recuperación automática

Cómo funciona

  • Interpreta todos los objetivos con el proceso (PID) como eje central
    • Puertos, servicios, contenedores y comandos se vinculan todos a un PID
    • Con base en el PID, construye una cadena causal de ejecución (causal chain)
  • Cuatro preguntas clave
    1. Qué está en ejecución
    2. Cómo se inició
    3. Qué lo mantiene en ejecución
    4. A qué contexto pertenece

Objetivos compatibles

  • Admite como entrada nombre de proceso/servicio, PID y número de puerto
    • Si al ingresar un nombre coinciden varios procesos, solicita elegir un PID
    • Con las opciones --pid y --port se puede hacer análisis basado en un proceso o puerto específico

Estructura de salida

  • Target: objetivo especificado por el usuario
  • Process: ejecutable, PID, usuario, comando, hora de inicio, número de reinicios
  • Why It Exists: linaje causal (ancestry chain) del proceso
  • Source: sistema principal responsable de la ejecución (por ejemplo, uno de systemd, docker, pm2, cron o shell)
  • Context: directorio de trabajo, repositorio Git, contenedor Docker, información de bind, etc.
  • Warnings: advertencias no bloqueantes como ejecución con privilegios de root, escucha en interfaces públicas, ejecución prolongada, uso excesivo de memoria, etc.

Opciones de línea de comandos

  • --pid, --port: análisis de un PID o puerto específico
  • --short: resumen en una línea
  • --tree: muestra el árbol completo de procesos
  • --json: salida en formato JSON
  • --warnings: muestra solo advertencias
  • --no-color: desactiva los colores
  • --env: muestra solo variables de entorno
  • --help: muestra la ayuda

Instalación y eliminación

  • Se distribuye como un binario estático único para Linux
  • Instalación con script (recomendada)
  • Instalación manual
    • Descarga directa de binarios para amd64 y arm64, y verificación de checksum
    • Después de dar permisos de ejecución, se mueve al PATH
  • Verificación y eliminación
    • Se puede verificar con witr --version y man witr
    • Se puede eliminar con sudo rm -f /usr/local/bin/witr
  • Compatibilidad con Nix Flake: se puede ejecutar con nix run github:pranshuparmar/witr -- --port 5000

Plataforma y permisos

  • Solo para Linux
  • Recopila información a través del acceso a /proc
    • Para consultar información de algunos procesos, se requieren privilegios de sudo

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-12-27
Opiniones de Hacker News

  • Sugieren que el GIF en bucle del README se reinicia demasiado rápido y cuesta leer toda la salida
    Estaría bien que se quedara quieto unos segundos más

    • Sinceramente, creo que una captura de pantalla es mejor que un GIF
      Con ver el último fotograma ya se transmite toda la información necesaria
    • ¡Gracias por el feedback! Al principio me parecía bien, pero visto desde la perspectiva del usuario sí resultaba bastante incómodo
      Ya lo cambié por una imagen estática y agradezco todas las sugerencias
    • Yo tampoco creo que el GIF sea realmente necesario
      Muestra que el comando es rápido, pero todo ya está en el último fotograma y además es menos eficiente en ancho de banda
    • En realidad, la solución más simple es quitar la animación por completo
      Basta con dejarla detenida al 100% en la pantalla de salida. Todo el mundo ya sabe cómo se ve alguien escribiendo en una terminal
    • Para crear este tipo de GIF automáticamente, utilidades como charmbracelet/vhs son muy útiles

  • Esta herramienta no busca reemplazar las herramientas de monitoreo/observación existentes
    Sirve para entender rápido, al conectarte por SSH, “¿por qué se está ejecutando esto?”
    Está dispuesto a ajustar el rumbo según el feedback

    • Me parece una idea realmente muy ingeniosa
      Siempre ha sido difícil averiguar para qué sirve un proceso cuando de repente empieza a consumir muchos recursos
      Al principio pensé que también explicaba la función del proceso, pero no era eso
      Aun así, es una gran herramienta. Más adelante podría ampliarse combinando la página man + una base de datos de procesos

  • Parece útil, pero por ahora la salida muestra sobre todo el ppid, así que te dice “quién lo ejecutó” más que “por qué se ejecutó”
    Está bien que soporte varios formatos de salida. Pensando en entornos automatizados, sería aún mejor que el valor por defecto fuera JSON o un formato amigable para grep

    • ¡Gracias por el feedback! Estoy revisando cómo mostrar con más claridad la diferencia entre “quién” y “por qué”
      La salida por defecto está pensada para que sea fácil de leer para humanos, pero ya existe soporte para automatización con una bandera JSON
      También voy a pensar en una forma más fácil de filtrar con grep

  • La herramienta es interesante, pero no me gusta instalar un binario con curl
    Más adelante pueden surgir preguntas como “¿cómo se instaló esto?” o “¿están al día los parches de seguridad?”
    Estaría bueno que hubiera paquetes deb o snap

    • Entiendo que la instalación con curl no les sirve a todos
      Como es la primera versión, empecé por algo simple, pero si gana popularidad planeo hacer distribución oficial en paquetes
    • Parece que pronto tendremos un nuevo comando de utilidad: wdtci: “what does this curl install?”
    • Como referencia, con systemctl status $pid también se puede obtener bastante información

  • La frase “witr se basa en la confianza” y la explicación de que fue desarrollado con ayuda de IA/LLM se sienten contradictorias

    • La frase “a veces fue supervisado por un humano que sabía lo que hacía” parece un chiste, pero si se lee en serio da algo de desconfianza
      Si los resultados del LLM se revisan y el código pasa por una revisión adecuada, creo que puede ser confiable
      Aun así, valoro que se haya dicho de forma transparente que se usó un LLM
    • Sí, esa frase iba en tono de humor y el LLM solo cumplió un papel de apoyo
      Las decisiones reales las tomó una persona
    • Para mí, si el código funciona bien, eso basta
      Si se desarrolló con foco en el resultado, me parece bien
    • Aun así, sigue siendo fácil que un malware falsifique las relaciones entre procesos
    • Sinceramente, creo que un LLM podría entender mejor el contexto que una persona

  • Es una herramienta realmente genial y útil
    Pero en un entorno de producción cuesta usarla de inmediato por las razones mencionadas arriba
    Ojalá haya paquetes Debian o RPM

    • ¡Gracias! Como es la primera versión, empecé por algo simple, pero si gana popularidad voy a preparar paquetes oficiales

  • Si quieres compilarla directamente desde el código fuente, puedes usar este comando

    CGO_ENABLED=0 go build -ldflags "-X main.version=dev -X main.commit=$(git rev-parse --short HEAD) -X 'main.buildDate=$(date +%Y-%m-%d)'" -o witr ./cmd/witr

    Personalmente, si existe un install.sh, esperaría que instale primero desde el código fuente local
    Ese es el tipo de cosas que hace que estas herramientas simples se queden siempre en mi terminal

    • ¡Gracias! Gracias a @sestep ya se agregó soporte para Nix, así que no hay de qué preocuparse por el binario
    • O si no, simplemente puedes usar el PR de Nix

  • Me pregunto qué significa “Git repository name and branch”
    ¿Es una función para detectar si el proceso en ejecución se lanzó dentro de un repositorio Git?

  • La idea está muy buena. Antes yo tenía un alias llamado “whodis” para encontrar el PID que abría un puerto, pero esto es mucho más potente

    • ¡Gracias! El objetivo es ser una navaja suiza de información de PID

  • Es una herramienta realmente impresionante. Gracias por compartirla
    ¿Te molestaría si yo hiciera un paquete AUR?

    • ¡Claro que no! Qué genial lo del registro en AUR. Muchas gracias
    • Yo no soy el autor, pero estaría buenísimo que hubiera una versión en AUR
      Una de las ventajas de Arch es que este tipo de herramientas interesantes aparecen en AUR súper rápido