Show HN: 인터랙티브 Systemd – Systemd 유닛 작업의 개선된 방법

 (isd-project.github.io)
2P by GN⁺ | ★ favorite | 댓글 1개
  • isd는 systemd 유닛을 관리하는 더 나은 방법을 제공하는 도구로, 터미널 사용자 인터페이스(TUI)를 통해 유닛을 검색하고 미리보기를 자동으로 갱신하며, 스마트한 sudo 처리와 사용자 맞춤형 인터페이스를 제공함

짧은 동기

  • isd는 systemd 유닛과 상호작용하는 데 필요한 복잡한 과정을 단순화하여 사용자에게 유용한 정보를 제공함
  • systemctl 명령어를 반복적으로 입력하는 번거로움을 줄이고, 자동으로 출력 결과를 갱신함

설치

  • isd는 AppImage, nix, uv를 통해 설치 가능함
  • AppImage는 모든 Linux 배포판에서 실행할 수 있는 단일 실행 파일로, 권한이 제한된 원격 서버에서도 사용 가능함
  • nix 환경에서 isd를 설치하려면, nix 패키지를 사용하여 설치 가능함
  • uv는 Python 패키지 관리자로, uv를 통해 isd를 설치하고 관리할 수 있음

isd 사용법

  • isd는 systemd 유닛을 검색하고 상태를 확인하며, 여러 유닛의 상세 정보를 미리보기로 제공함
  • 선택한 유닛에 systemctl 명령어를 보내고 상태 출력을 자동으로 갱신함
  • isd 내에서 pager를 열어 전체 상태 출력을 확인할 수 있음
  • Journal 출력에 대한 별도의 pager를 열 수 있으며, 사용자 맞춤형 테마와 키 바인딩을 설정할 수 있음

사용자/시스템 모드

  • isd는 user 또는 system 모드로 실행되며, 각 모드에 따라 표시되는 유닛 유형이 달라짐

퍼지 검색

  • 퍼지 검색 바를 통해 입력된 내용과 일치하는 모든 유닛과 유닛 파일을 로드하고, 현재 상태에 따라 강조 표시함

여러 유닛 선택

  • 검색 결과 위젯에서 여러 유닛을 선택할 수 있으며, 선택된 유닛의 미리보기를 제공함

명령 팔레트

  • 명령 팔레트를 열어 사용 가능한 모든 명령과 키 바인딩을 확인할 수 있음

명령어

  • 예를 들어, Ctrl+O를 눌러 선택한 유닛을 중지할 수 있음

페이저 지원

  • isd를 실행하면서 pager를 열어 전체 미리보기 출력을 확인할 수 있음

사용자 맞춤화

  • isd는 사용자 맞춤화와 구성 가능성을 제공하며, 사용자가 최적의 생산성을 발휘할 수 있도록 다양한 테마와 키 바인딩을 제공함

요약

  • isd가 유용할지 판단하기 위해 직접 사용해보는 것을 권장함

다음 단계

  • 사용자 맞춤화 및 보안 섹션을 확인할 것

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 보기 좋음
    systemd 서비스 스크립트에서 ExecStop 처리 방식이 정말 헷갈렸음
    ExecStart는 시스템 부팅 때나 사용자가 서비스를 시작할 때 실행할 명령인데, ExecStop은 시작 명령이 끝난 뒤 실행됨
    시스템 종료나 사용자가 서비스를 멈출 때 stop 명령이 실행되게 하려면 RemainAfterExit=yes를 설정해야 함
    ExecStop은 사실상 “서비스 종료용” 이벤트라기보다 “정리 시점” 이벤트에 가까움

    • “시작 시”와 “중지 시”로 생각하면 됨
      systemd는 데몬에 맞춰져 있다는 점을 기억해야 함
      서비스가 언젠가 종료되는 명령 하나만 실행한다면, systemd에게 데몬과 다르게 취급하라고 명시해야 함
      다른 사람들이 말했듯이 아마 oneshot + RemainAfterExit가 원하는 조합일 가능성이 큼
    • type=forking에서는 ExecStop이 기대한 방식으로 동작함

  • 정말 마음에 듦
    아플 때까지 순수 명령줄만 쓰다가, 최근 lazygit/lazydocker 같은 도구로 불투명한 시스템/트리 상태를 들여다보기 시작했는데 생산성이 크게 올라갔음
    사용자 및 시스템 수준 서비스를 여러 개 관리하지만 디버깅은 지루함
    첫 문장에서 흔한 명령들과 그 불편함을 나열한 부분이 정말 와닿았음
    NixOS라서 불변 unit 파일을 직접 편집하는 방식은 안 되겠지만, 서비스 탐색·가시성·관리는 큰 도움이 될 듯함

    • 나도 NixOS 사용자이고, 바로 그 점 때문에 이 프로젝트를 만들게 됨
      문서에 “가이드”를 추가할 계획인데, 요약하면 NixOS에서 unit을 디버깅할 때 systemctl edit --runtime을 확인해보면 좋음
      디버깅이 훨씬 쉬워짐

  • 아주 좋아 보임
    비슷한 프로젝트를 유지보수하고 있는데 systemd/dbus API를 다루는 일이 꽤 고통스러웠음
    이걸 써보면서 배울 수 있는 게 있는지 보고 싶음
    https://github.com/rgwood/systemctl-tui

    • 엄청남
      많이 쓰게 될 듯함
      빠진 건 deb 패키지뿐임

  • 드디어 systemd-client가 나왔군, 반가움
    다음 단계는 macOS, FreeBSD, Windows 같은 비 Linux용 TUI였으면 함
    macOS에서는 LaunchControl.app을 쓰지만 TUI는 아님
    한 가지로, uv 0.5.21에서는 아래처럼 해야 했고 uvx는 전혀 안 됐음
    $ uv tool install git+https://github.com/isd-project/isd
    대신 문서의 $ uv tool install https://github.com/isd-project/isd/isd@latest는 안 됐음
    그래도 uv가 pip(x)보다 훨씬 빨라서 갈아탔음

    • 실수였고 이제 고쳐짐
      알려줘서 고마움

  • uv 덕분에 이런 도구 설치가 이렇게 쉬워지는 게 멋짐
    설치 절차에서 빠진 건, uv가 Python 의존성을 무시하고 이 도구를 설치한다는 점임
    내 머신은 3.10이라 isd가 동작하지 않았고, -p 3.13 옵션으로 해결했음
    문서에 언급할 만함

    • 알려줘서 고마움
      해당 플래그를 문서에 포함했음

  • “입력하다가 짜증난 적이 있다면”이라니, 딱 내 얘기임
    systemd를 좋아하는데도 그럼
    아직 설치는 안 해봤는데, 원격 호스트에 연결할 수 있는지 궁금함
    systemctl --host status foo.service를 자주 쓰고, status, timers, logs 등을 원격에서 확인함

    • systemctl --host는 처음 들어봄
      아쉽게도 지원하지 않음
      대략 로컬 systemctl을 감싼 화려한 래퍼에 가까움
      그래도 AppImage가 있어서 원격 서버에서 실행하기는 hopefully 쉬울 수 있음
      어쨌든 이슈를 열어주면 살펴보겠음

  • 원격 서버나 Docker 이미지에는 이런 걸 설치할 수 없음
    명령 실행과 정보 수집을 위한 여러 백엔드가 필요함: 로컬, SSH, Docker
    로컬에 설치한 뒤 SSH로 원격 머신에서 명령을 실행하고, docker exec로도 실행할 수 있어야 함

  • “Nix가 설치되어 있으면 이 AppImage는 동작하지 않습니다”가 정말 맞는지 의문임
    NixOS에서 안 되는 이유는 이해함. 호스트의 systemctl을 실행하지 못하는 것처럼 보였음
    하지만 단순히 다른 OS에 Nix만 설치된 경우까지 안 될 이유는 없어 보임
    흥미롭게도 Nix v2.24.11에서는 제공된 Nix 명령도 안 됐음
    $ nix run https://github.com/isd-project/isd가 Failed to open archive (Unrecognized archive format)로 실패함
    Git URL 형태로 바꾸면 동작할 수도 있지만, Nix에는 더 효율적인 기본 GitHub fetcher가 있으니 실제 명령은 nix run github:isd-project/isd가 맞아 보임
    이 프로젝트 자체는 멋짐
    원래 systemd의 DBus API와 Qt로 비슷한 걸 만들고 싶었고 코드도 조금 작성했음
    DBus API는 필요한 기능을 거의 제공할 가능성이 높음. 물론 자체 SSH 터널링을 구현하는 것보다 systemd -H를 호출하는 편이 훨씬 쉽긴 함
    systemd와 현대 Linux에는 시스템 관리, 특히 전통적으로 내부가 잘 안 보이던 데스크톱 관리를 쉽게 해줄 데이터와 인터페이스가 넘쳐나는데도 노출이 잘 안 되는 점이 답답함
    예전에는 xdg 자동 시작 앱이 실패했을 때 무슨 일이 일어났는지 알기 어려웠지만, 이제 일부 데스크톱에서 systemd가 xdg 자동 시작 앱을 실행하니 실패한 자동 시작 항목과 로그 뷰어를 보여주는 GUI를 만들기 쉬움
    그런데 유지보수되고 기능이 비교적 완성된 도구는 없는 것 같아 꽤 답답함

    • 맞음, 복잡해져서 권장하면서 세부를 설명하고 싶지는 않았음
      요약하면 AppImage를 nix로 생성하고, AppImage가 AppImage 내부의 /nix/ 디렉터리를 “마운트”함. 오버레이는 아님
      그래서 TUI에서 /nix/에 접근하는 호출은 시스템의 /nix 디렉터리로 가지 않고, 온갖 이상한 문제가 생김
      예를 들어 Ubuntu에서 home-manager로 EDITOR를 설치할 수 있음
      systemctl은 “접근 가능”하니 isd는 정상 시작되지만, /nix 아래의 EDITOR를 열면 찾지 못해서 사용자 입장에서는 매우 혼란스러움
      그래서 이미 Nix를 쓰고 있다면 Nix 설치 방식을 쓰라고 말하는 게 더 쉬움
      잘못된 문서는 이제 고쳤음
      그 답답함에도 공감함
      개인적으로 그런 도구를 만들면 정말 재미있겠지만 쉬운 작업은 아니고, 누가 그 일을 지원해줄지도 문제임
      이 TUI는 범위가 관리 가능했는데도 꽤 많은 작업이었음
      그래서 “상위 수준 인터페이스”에 너무 많이 투자할 것 같지는 않음
      덧붙여, 왜 원 댓글 반응이 안 좋은지는 모르겠음
    • 왜 이 댓글 반응이 안 좋은지 전혀 이해가 안 됨
      누가 설명해줄 수 있나?

  • 훌륭해 보이고 잘 만들었음
    다만 이런 도구가 필요하다는 사실 자체가 아쉬움
    systemd와의 상호작용 대부분은 사소함: 서비스 재시작, 로그 파일을 보고 뭐가 잘못됐는지 확인, 부팅 시 서비스가 시작되는지 확인
    이런 흔한 작업에서 systemd의 사용성이 이렇게 부족하다는 게 이해가 안 됨
    그래도 이 TUI가 도움이 되는 듯하니 고마움
    물론 systemd는 initd와 달리 더 결정적이고 온갖 기능을 다 포함
    다행히 요즘은 이런 상호작용 대부분을 자동화해서 사라지게 할 수 있어, 예전 같은 불타는 증오는 더 이상 없음
    지금은 잔불 같은 정도임

    • systemd에 복잡하고 주관적인 TUI를 넣어 “비대하게” 만들고 싶지 않은 이유는 이해함
      그래도 좀 더 상류 프로젝트에 가까운 인터페이스가 있었으면 정말 좋았을 것임
      다만 systemd를 초보자 친화적이고 접근 가능하게 만드는 일이 그들의 자금 지원에서 그리 중요하지는 않은 듯함

  • 보안은 어떻게 처리됨?
    Linux가 잘 처리하는 시스템 권한 얘기가 아니라, 외부 공격자에게 탈취되어 원격 제어되지 않는다는 보장이 궁금함

    • 작성자임
      sudo로 뭔가를 하는 애플리케이션이나 스크립트를 실행할 때 스스로 물어봐야 할 중요한 질문이라고 생각함
      그래서 isd 문서 페이지에 꽤 자세한 Security 섹션을 작성해뒀음
      https://isd-project.github.io/isd/security/
      빠진 게 있으면 알려주면 좋겠음
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.