Bosun vs lsof: ¿cuándo vale la pena una app de barra de menú sobre una línea de comando?

Partamos por lo incómodo. Si sabes el número del puerto y solo quieres que se vaya lo que lo está ocupando, lsof ya resuelve eso, ya está en tu Mac y no cuesta nada:

lsof -ti :3000 | xargs kill

Ese es el punto de partida honesto, y cualquier comparación que finja lo contrario te está haciendo perder el tiempo. Así que la pregunta real no es cuál mata un proceso más rápido, es cuándo la línea de comando deja de ser la herramienta correcta.

Qué hace realmente ese comando

Vale la pena entenderlo, porque es mejor de lo que la mayoría cree.

El flag -t hace que lsof imprima solo los IDs de proceso, sin nada más. xargs toma todos esos IDs y se los pasa a un solo kill. Entonces si cuatro procesos ocupan el puerto 3000, que es lo que pasa con servidores multi worker como gunicorn, Odoo o un Node en cluster, los cuatro reciben la señal de una vez.

Lo puedes comprobar tú mismo. Levanta un servidor con un supervisor y tres workers, y después:

lsof -ti :9911
# 39238 39271 39272 39273

lsof -ti :9911 | xargs kill
# el puerto queda libre, los cuatro se fueron

Un kill sin argumentos manda SIGTERM, que le da al proceso la oportunidad de cerrar bien. Si algo lo ignora y el puerto sigue ocupado, -9 fuerza la salida:

lsof -ti :3000 | xargs kill -9

Usa primero la versión amable. SIGKILL no le da al proceso ninguna posibilidad de guardar lo que tenga pendiente.

Dónde se queda corto

El comando funciona cuando ya sabes qué estás buscando. Se debilita en tres situaciones.

No sabes cuál es el puerto. lsof -i -P -n -sTCP:LISTEN te lista todo lo que está escuchando, pero la salida es un muro de texto sin orden, sin agrupación, y con las entradas IPv4 e IPv6 duplicadas para el mismo proceso. Lo lento es leerlo, no escribirlo.

El nombre del proceso no te dice nada. Docker es el caso clásico. Cada puerto publicado de un contenedor pertenece a un proceso llamado docker-proxy, así que lsof te muestra seis filas idénticas y ninguna forma de saber cuál es cuál. Lo mismo pasa con un node o un python pelado cuando tienes varios proyectos abiertos.

Lo que se te olvidó abierto no es un puerto. Un túnel de ngrok o un quick tunnel de cloudflared es una ruta viva desde internet hacia tu notebook. No aparece en un listado de puertos de ninguna forma que lo identifique. Una conexión VPN activa tampoco. Si lo que quieres responder es qué está exponiendo tu Mac ahora mismo, lsof no es la pregunta correcta.

Qué agrega Bosun

Bosun corre el mismo lsof por debajo. No es otra forma de leer el kernel, es otra forma de leer la salida, y mantenerla siempre visible.

Agrupa por número de puerto, así un servicio multi worker se colapsa en una fila con la cuenta de workers en vez de ocho líneas iguales. Traduce docker-proxy de vuelta a la imagen del contenedor y el proyecto de Compose. Detecta túneles de ngrok y de Cloudflare, incluidos los quick tunnels, y te muestra la URL pública. Te indica si hay una VPN nativa de macOS conectada. Guarda historial, así puedes ver qué estaba escuchando antes y no solo ahora.

Nada de eso es imposible desde la terminal. Son varios comandos, algunos que tendrías que ir a buscar, y tendrías que acordarte de correrlos.

Una recomendación honesta

Situación	Usa
Sabes el puerto y lo quieres libre, ahora	lsof -ti :PUERTO | xargs kill
Scripts, CI, una máquina remota por SSH	lsof, siempre
No estás en macOS	lsof, Bosun es solo para macOS
¿Qué está corriendo en esta máquina ahora?	Bosun
Varios contenedores Docker peleando por puertos	Bosun
Verificar si quedó un túnel abierto a internet	Bosun

Si pasas el día en un proyecto con un solo servidor de desarrollo, apréndete la línea de comando y sáltate la app. En serio. Bosun es para quien corre varios servicios a la vez, o túneles, o una pila de contenedores, y quiere la respuesta visible sin tener que ir a buscarla.

Bosun es una app de barra de menú para macOS con 14 días de prueba gratis y sin registro. Necesita macOS 14 o posterior.