Show HN: Systemd interativo – uma forma melhor de trabalhar com unidades do Systemd

 (isd-project.github.io)
2 pontos por GN⁺ 2025-01-19 | 1 comentários | Compartilhar no WhatsApp
  • isd é uma ferramenta que oferece uma maneira melhor de gerenciar unidades do systemd, permitindo pesquisar unidades por meio de uma interface de usuário de terminal (TUI), atualizar automaticamente as prévias e oferecendo tratamento inteligente de sudo e uma interface personalizável

Motivação curta

  • isd simplifica o processo complexo necessário para interagir com unidades do systemd, fornecendo informações úteis ao usuário
  • Reduz o incômodo de digitar repetidamente comandos systemctl e atualiza automaticamente os resultados de saída

Instalação

  • isd pode ser instalado via AppImage, nix e uv
  • AppImage é um único executável que pode rodar em qualquer distribuição Linux, podendo ser usado até em servidores remotos com permissões restritas
  • Para instalar o isd em um ambiente nix, é possível usar o pacote nix
  • uv é um gerenciador de pacotes Python, e o isd pode ser instalado e gerenciado por meio dele

Como usar o isd

  • isd permite pesquisar unidades do systemd, verificar o estado delas e fornecer prévias com informações detalhadas de várias unidades
  • Envia comandos systemctl para a unidade selecionada e atualiza automaticamente a saída de status
  • É possível abrir o pager dentro do isd para ver a saída completa de status
  • Também é possível abrir um pager separado para a saída do Journal, além de configurar temas e atalhos de teclado personalizados

Modo usuário/sistema

  • isd roda nos modos user ou system, e o tipo de unidades exibidas varia conforme o modo

Busca fuzzy

  • Por meio da barra de busca fuzzy, carrega todas as unidades e arquivos de unidade que correspondem ao texto digitado e os destaca de acordo com o estado atual

Seleção de várias unidades

  • É possível selecionar várias unidades no widget de resultados de busca e visualizar a prévia das unidades selecionadas

Paleta de comandos

  • É possível abrir a paleta de comandos para ver todos os comandos disponíveis e seus atalhos de teclado

Comandos

  • Por exemplo, pressionando Ctrl+O, é possível parar a unidade selecionada

Suporte a pager

  • Ao executar o isd, é possível abrir o pager para ver toda a saída da prévia

Personalização

  • isd oferece personalização e configurabilidade, com vários temas e atalhos de teclado para ajudar o usuário a alcançar a melhor produtividade

Resumo

  • Recomenda-se experimentar o isd diretamente para avaliar se ele será útil

Próximos passos

  • Verifique as seções de personalização e segurança

Leituras relacionadas

1 comentários

 
GN⁺ 2025-01-19
Opiniões no Hacker News

  • Parece bom
    A forma como o ExecStop é tratado em scripts de serviço do systemd era realmente confusa
    ExecStart é o comando executado na inicialização do sistema ou quando o usuário inicia o serviço, mas ExecStop é executado depois que o comando de inicialização termina
    Para fazer com que o comando de stop seja executado no desligamento do sistema ou quando o usuário para o serviço, é preciso definir RemainAfterExit=yes
    Na prática, ExecStop está mais para um evento de “momento de limpeza” do que para um evento de “encerramento do serviço”

    • Dá para pensar como “ao iniciar” e “ao parar”
      É preciso lembrar que o systemd é voltado para daemons
      Se o serviço executa apenas um comando que termina em algum momento, você precisa dizer explicitamente ao systemd para tratá-lo de forma diferente de um daemon
      Como outras pessoas disseram, provavelmente oneshot + RemainAfterExit é a combinação que você quer
    • Em type=forking, ExecStop funciona da forma esperada

  • Gostei muito
    Usei só linha de comando pura até cansar, e recentemente comecei a usar ferramentas como lazygit/lazydocker para enxergar estados opacos de sistemas/árvores, e minha produtividade aumentou bastante
    Gerencio vários serviços em nível de usuário e de sistema, mas depurar é tedioso
    A parte da primeira frase que enumera comandos comuns e seus incômodos bateu muito comigo
    Como uso NixOS, editar diretamente arquivos de unit imutáveis não vai funcionar, mas a exploração, visibilidade e gestão de serviços devem ajudar muito

    • Também sou usuário de NixOS, e foi exatamente por isso que acabei criando este projeto
      Pretendo adicionar um “guia” à documentação, mas, em resumo, ao depurar units no NixOS, vale a pena experimentar systemctl edit --runtime
      A depuração fica muito mais fácil

  • Parece muito bom
    Mantenho um projeto parecido, e lidar com a API systemd/dbus foi bem doloroso
    Quero testar este para ver se consigo aprender algo
    https://github.com/rgwood/systemctl-tui

    • Impressionante
      Acho que vou usar bastante
      A única coisa que falta é um pacote deb

  • Finalmente saiu um systemd-client, que bom
    Tomara que o próximo passo seja uma TUI para sistemas não Linux, como macOS, FreeBSD e Windows
    No macOS eu uso o LaunchControl.app, mas ele não é TUI
    Uma observação: no uv 0.5.21, tive que fazer como abaixo, e uvx não funcionou de jeito nenhum
    $ uv tool install git+https://github.com/isd-project/isd
    Por outro lado, o comando da documentação, $ uv tool install https://github.com/isd-project/isd/isd@latest, não funcionou
    Ainda assim, o uv é muito mais rápido que pip(x), então migrei

    • Foi um erro e já foi corrigido
      Obrigado por avisar

  • É legal ver como o uv torna tão fácil instalar ferramentas desse tipo
    O que faltou no procedimento de instalação é que o uv ignora as dependências de Python ao instalar esta ferramenta
    Minha máquina estava na 3.10, então o isd não funcionava, e resolvi com a opção -p 3.13
    Vale a pena mencionar isso na documentação

    • Obrigado por avisar
      Incluí essa flag na documentação

  • “Se você já ficou irritado digitando” — isso sou eu
    Mesmo gostando do systemd
    Ainda não instalei, mas queria saber se dá para conectar a hosts remotos
    Uso bastante systemctl --host status foo.service e verifico status, timers, logs etc. remotamente

    • Nunca tinha ouvido falar de systemctl --host
      Infelizmente não há suporte
      Em linhas gerais, é mais como um wrapper sofisticado em torno do systemctl local
      Ainda assim, como há um AppImage, hopefully pode ser fácil executá-lo em um servidor remoto
      De todo modo, se você abrir uma issue, vou dar uma olhada

  • Não dá para instalar algo assim em servidores remotos ou imagens Docker
    São necessários vários backends para executar comandos e coletar informações: local, SSH, Docker
    Depois de instalado localmente, ele deveria conseguir executar comandos em uma máquina remota via SSH e também via docker exec

  • Fico em dúvida se “este AppImage não funciona se o Nix estiver instalado” é realmente correto
    Entendo por que não funciona no NixOS. Parecia não conseguir executar o systemctl do host
    Mas não vejo motivo para não funcionar quando o Nix está apenas instalado em outro sistema operacional
    Curiosamente, no Nix v2.24.11, nem o comando Nix fornecido funcionou
    $ nix run https://github.com/isd-project/isd falhou com Failed to open archive (Unrecognized archive format)
    Talvez funcione se for alterado para o formato de URL Git, mas como o Nix tem um fetcher nativo do GitHub mais eficiente, o comando correto parece ser nix run github:isd-project/isd
    O projeto em si é bacana
    Eu originalmente queria criar algo parecido com a API DBus do systemd e Qt, e até escrevi um pouco de código
    A API DBus provavelmente oferece quase todos os recursos necessários. Claro que chamar systemd -H é muito mais fácil do que implementar seu próprio tunelamento SSH
    É frustrante que o systemd e o Linux moderno tenham tantos dados e interfaces que poderiam facilitar a administração do sistema, especialmente a administração de desktops, que tradicionalmente era pouco transparente por dentro, mas isso ainda seja pouco exposto
    Antes era difícil saber o que tinha acontecido quando um app de inicialização automática xdg falhava, mas agora, como em alguns desktops o systemd executa esses apps de inicialização automática xdg, é fácil criar uma GUI que mostre os itens de inicialização automática com falha e um visualizador de logs
    Só que parece não haver nenhuma ferramenta mantida e relativamente completa em recursos, o que é bem frustrante

    • Sim, ficou complicado, então eu não queria recomendar e ao mesmo tempo explicar os detalhes
      Em resumo, o AppImage é gerado com nix, e o AppImage “monta” o diretório /nix/ de dentro do próprio AppImage. Não é um overlay
      Por isso, chamadas que acessam /nix/ na TUI não vão para o diretório /nix do sistema, e todo tipo de problema estranho acontece
      Por exemplo, no Ubuntu, você pode instalar o EDITOR com home-manager
      Como systemctl está “acessível”, o isd inicia normalmente, mas, ao abrir o EDITOR em /nix, ele não é encontrado, o que é muito confuso para o usuário
      Então é mais fácil dizer que, se você já usa Nix, use o método de instalação via Nix
      A documentação incorreta já foi corrigida
      Também compartilho essa frustração
      Pessoalmente, eu acharia muito divertido criar uma ferramenta dessas, mas não é uma tarefa fácil, e também há a questão de quem apoiaria esse trabalho
      Mesmo esta TUI, com um escopo administrável, deu bastante trabalho
      Por isso, não acho que vou investir demais em uma “interface de nível mais alto”
      Além disso, não sei por que a reação ao comentário original está negativa
    • Não entendo de jeito nenhum por que a reação a este comentário está negativa
      Alguém consegue explicar?

  • Parece excelente e bem feito
    Só é uma pena que uma ferramenta dessas seja necessária
    A maior parte das interações com o systemd é trivial: reiniciar um serviço, ver o arquivo de log para entender o que deu errado, verificar se um serviço inicia no boot
    Não entendo como a usabilidade do systemd pode ser tão deficiente nessas tarefas comuns
    Ainda assim, esta TUI parece ajudar, então obrigado
    Claro, ao contrário do initd, o systemd é mais determinístico e inclui todo tipo de recurso
    Felizmente, hoje em dia dá para automatizar e fazer desaparecer a maioria dessas interações, então aquele ódio ardente de antes já não existe
    Agora é mais como brasas

    • Entendo por que não se quer deixar o systemd “inchado” colocando nele uma TUI complexa e subjetiva
      Mesmo assim, teria sido muito bom haver uma interface mais próxima do projeto upstream
      Mas parece que tornar o systemd amigável para iniciantes e acessível não é tão importante no financiamento deles

  • Como a segurança é tratada?
    Não estou falando das permissões do sistema, que o Linux lida bem, mas sim de que garantia há de que ele não será sequestrado por um invasor externo e controlado remotamente

    • Sou o autor
      Acho que essa é uma pergunta importante que você deve se fazer ao executar uma aplicação ou script que faz algo com sudo
      Por isso escrevi uma seção Security bem detalhada na página de documentação do isd
      https://isd-project.github.io/isd/security/
      Se houver algo faltando, eu gostaria que você me avisasse