Show HN: Interactive Systemd – una forma mejorada de trabajar con unidades de Systemd

 (isd-project.github.io)
2 puntos por GN⁺ 2025-01-19 | 1 comentarios | Compartir por WhatsApp
  • isd es una herramienta que ofrece una mejor manera de administrar unidades de systemd, con una interfaz de usuario de terminal (TUI) para buscar unidades, actualizar automáticamente la vista previa y ofrecer un manejo inteligente de sudo junto con una interfaz personalizable.

Motivación breve

  • isd simplifica el proceso complejo necesario para interactuar con unidades de systemd y proporciona información útil al usuario.
  • Reduce la molestia de tener que escribir repetidamente comandos systemctl y actualiza automáticamente los resultados de salida.

Instalación

  • isd puede instalarse mediante AppImage, nix y uv.
  • AppImage es un ejecutable único que puede ejecutarse en cualquier distribución de Linux, por lo que también puede usarse en servidores remotos con permisos restringidos.
  • Para instalar isd en un entorno nix, puede usarse el paquete de nix.
  • uv es un gestor de paquetes de Python; mediante uv se puede instalar y administrar isd.

Cómo usar isd

  • isd permite buscar unidades de systemd, revisar su estado y mostrar una vista previa con información detallada de varias unidades.
  • Envía comandos systemctl a la unidad seleccionada y actualiza automáticamente la salida de estado.
  • Dentro de isd, se puede abrir un pager para ver la salida completa del estado.
  • También se puede abrir un pager separado para la salida de Journal, y configurar temas y atajos de teclado personalizados.

Modo usuario/sistema

  • isd se ejecuta en modo user o system, y el tipo de unidades mostradas cambia según el modo.

Búsqueda difusa

  • A través de la barra de búsqueda difusa, carga todas las unidades y archivos de unidad que coinciden con lo ingresado, y los resalta según su estado actual.

Selección de varias unidades

  • En el widget de resultados de búsqueda se pueden seleccionar varias unidades, y se ofrece una vista previa de las unidades seleccionadas.

Paleta de comandos

  • Se puede abrir la paleta de comandos para ver todos los comandos disponibles y sus atajos de teclado.

Comandos

  • Por ejemplo, al presionar Ctrl+O se puede detener la unidad seleccionada.

Soporte para pager

  • Mientras se ejecuta isd, se puede abrir un pager para ver la salida completa de la vista previa.

Personalización

  • isd ofrece personalización y posibilidades de configuración, con varios temas y atajos de teclado para que el usuario logre una productividad óptima.

Resumen

  • Se recomienda probar isd directamente para evaluar si te resulta útil.

Próximos pasos

  • Revisar las secciones de personalización y seguridad

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-01-19
Opiniones de Hacker News

  • Se ve bien
    La forma en que se maneja ExecStop en los scripts de servicio de systemd siempre me pareció muy confusa
    ExecStart es el comando que se ejecuta al arrancar el sistema o cuando el usuario inicia el servicio, pero ExecStop se ejecuta después de que termina el comando de inicio
    Para que el comando stop se ejecute al apagar el sistema o cuando el usuario detiene el servicio, hay que configurar RemainAfterExit=yes
    En realidad, ExecStop se parece más a un evento de “momento de limpieza” que a uno de “finalización del servicio”

    • Hay que pensarlo como “al iniciar” y “al detener”
      Hay que recordar que systemd está orientado a demonios
      Si un servicio solo ejecuta un comando que termina en algún momento, hay que indicarle explícitamente a systemd que lo trate distinto de un demonio
      Como dijeron otros, probablemente oneshot + RemainAfterExit sea la combinación que buscas
    • En type=forking, ExecStop funciona de la forma esperada

  • Me encanta
    Usé solo la línea de comandos pura hasta cansarme, y hace poco empecé a usar herramientas como lazygit/lazydocker para mirar dentro de sistemas/estados de árbol opacos, y mi productividad aumentó mucho
    Administro varios servicios a nivel de usuario y de sistema, pero depurarlos es tedioso
    Me pegó mucho la parte de la primera oración donde enumera comandos comunes y sus molestias
    Como uso NixOS, editar directamente archivos unit inmutables no funcionará, pero la exploración, visibilidad y administración de servicios parecen de gran ayuda

    • Yo también uso NixOS, y justamente por eso terminé creando este proyecto
      Planeo agregar una “guía” a la documentación; en resumen, al depurar units en NixOS conviene revisar systemctl edit --runtime
      Hace que la depuración sea mucho más fácil

  • Se ve muy bueno
    Mantengo un proyecto parecido y lidiar con la API de systemd/dbus fue bastante doloroso
    Quiero probar esto y ver si puedo aprender algo
    https://github.com/rgwood/systemctl-tui

    • Tremendo
      Creo que lo voy a usar mucho
      Lo único que falta es un paquete deb

  • Por fin salió un cliente para systemd, qué bueno
    Me gustaría que el siguiente paso fuera una TUI para sistemas no Linux como macOS, FreeBSD y Windows
    En macOS uso LaunchControl.app, pero no es TUI
    Un detalle: con uv 0.5.21 tuve que hacerlo así, y uvx no funcionó en absoluto
    $ uv tool install git+https://github.com/isd-project/isd
    En cambio, el $ uv tool install https://github.com/isd-project/isd/isd@latest de la documentación no funcionó
    Aun así, uv es mucho más rápido que pip(x), así que me cambié

    • Fue un error y ya está corregido
      Gracias por avisar

  • Es genial que gracias a uv instalar herramientas como esta sea tan fácil
    Lo que falta en el proceso de instalación es aclarar que uv instala esta herramienta ignorando las dependencias de Python
    Mi máquina está en 3.10, así que isd no funcionaba; lo solucioné con la opción -p 3.13
    Vale la pena mencionarlo en la documentación

    • Gracias por avisar
      Incluí esa bandera en la documentación

  • Eso de “si alguna vez te frustraste al escribir” me describe perfecto
    Y eso que me gusta systemd
    Todavía no lo instalé, pero me pregunto si puede conectarse a hosts remotos
    Uso mucho systemctl --host status foo.service, y reviso status, timers, logs, etc. de forma remota

    • Es la primera vez que oigo hablar de systemctl --host
      Lamentablemente no está soportado
      En términos generales, es más bien un wrapper elegante alrededor del systemctl local
      Aun así, como hay AppImage, hopefully podría ser fácil ejecutarlo en un servidor remoto
      De todos modos, si abres un issue, lo revisaré

  • En servidores remotos o imágenes Docker no se puede instalar algo así
    Se necesitan varios backends para ejecutar comandos y recopilar información: local, SSH, Docker
    Debería poder instalarse localmente y luego ejecutar comandos en una máquina remota por SSH, y también mediante docker exec

  • Dudo que sea realmente cierto eso de “si tienes Nix instalado, este AppImage no funciona”
    Entiendo por qué no funciona en NixOS. Parecía que no podía ejecutar el systemctl del host
    Pero no veo por qué no debería funcionar en otros sistemas operativos donde simplemente esté instalado Nix
    Curiosamente, con Nix v2.24.11 tampoco funcionó el comando de Nix proporcionado
    $ nix run https://github.com/isd-project/isd falla con Failed to open archive (Unrecognized archive format)
    Si se cambia al formato de URL de Git quizá funcione, pero como Nix tiene un fetcher nativo de GitHub más eficiente, el comando correcto parece ser nix run github:isd-project/isd
    El proyecto en sí está genial
    Originalmente quería hacer algo parecido con la API de DBus de systemd y Qt, e incluso escribí algo de código
    Es muy probable que la API de DBus ofrezca casi todo lo necesario. Claro que invocar systemd -H es mucho más fácil que implementar tu propio túnel SSH
    Me frustra que systemd y Linux moderno estén llenos de datos e interfaces que facilitarían la administración del sistema, especialmente la administración de escritorios, que tradicionalmente ha sido poco visible por dentro, pero que no estén bien expuestos
    Antes era difícil saber qué pasaba cuando fallaba una app de inicio automático de xdg, pero ahora, como en algunos escritorios systemd ejecuta esas apps de inicio automático de xdg, sería fácil crear una GUI que muestre los elementos de inicio automático fallidos y un visor de logs
    Sin embargo, no parece haber una herramienta mantenida y relativamente completa en funciones, lo cual es bastante frustrante

    • Sí, se volvió complejo y no quería recomendarlo teniendo que explicar todos los detalles
      En resumen, el AppImage se genera con nix, y el AppImage “monta” el directorio /nix/ dentro del propio AppImage. No es un overlay
      Por eso, las llamadas desde la TUI que acceden a /nix/ no van al directorio /nix del sistema, y aparecen todo tipo de problemas raros
      Por ejemplo, en Ubuntu puedes instalar EDITOR con home-manager
      Como systemctl está “accesible”, isd arranca normalmente, pero si abres el EDITOR bajo /nix, no lo encuentra, lo que resulta muy confuso para el usuario
      Por eso es más fácil decir que, si ya usas Nix, uses el método de instalación con Nix
      La documentación incorrecta ya la corregí
      También comparto esa frustración
      Personalmente, construir una herramienta así sería muy divertido, pero no es una tarea fácil, y también está el problema de quién apoyaría ese trabajo
      Esta TUI tenía un alcance manejable y aun así fue bastante trabajo
      Así que no creo que vaya a invertir demasiado en una “interfaz de más alto nivel”
      Además, no sé por qué el comentario original está recibiendo mala reacción
    • No entiendo para nada por qué este comentario está recibiendo mala reacción
      ¿Alguien puede explicarlo?

  • Se ve excelente y está bien hecho
    Pero me da pena que haga falta una herramienta como esta
    La mayoría de las interacciones con systemd son triviales: reiniciar un servicio, revisar los logs para ver qué salió mal, verificar si un servicio arranca al iniciar el sistema
    No entiendo cómo la usabilidad de systemd puede ser tan deficiente en tareas tan comunes
    Aun así, parece que esta TUI ayuda, así que gracias
    Por supuesto, a diferencia de initd, systemd es más determinista e incluye todo tipo de funciones
    Por suerte, hoy en día se puede automatizar la mayoría de estas interacciones hasta hacerlas desaparecer, así que ya no le tengo el odio ardiente de antes
    Ahora es más bien como brasas

    • Entiendo por qué no querrían “inflar” systemd metiéndole una TUI compleja y subjetiva
      Aun así, habría sido muy bueno tener una interfaz más cercana al proyecto upstream
      Pero parece que hacer que systemd sea amigable y accesible para principiantes no es tan importante dentro de su financiamiento

  • ¿Cómo se maneja la seguridad?
    No me refiero a los permisos del sistema, que Linux maneja bien, sino a qué garantía hay de que no pueda ser comprometido por un atacante externo y controlado remotamente

    • Soy el autor
      Creo que es una pregunta importante que uno debe hacerse al ejecutar una aplicación o script que hace algo con sudo
      Por eso escribí una sección de Security bastante detallada en la página de documentación de isd
      https://isd-project.github.io/isd/security/
      Si falta algo, agradecería que me avisaras