Show HN: インタラクティブ Systemd – Systemd ユニット作業の改善された方法
(isd-project.github.io)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が役に立つかどうか判断するために、実際に使ってみることを勧める
次のステップ
- カスタマイズおよびセキュリティのセクションを確認すること
1件のコメント
Hacker News のコメント
見た目がよい
systemd のサービススクリプトで ExecStop がどう扱われるのか、本当に混乱していた
ExecStartはシステム起動時やユーザーがサービスを開始したときに実行するコマンドだが、ExecStopは開始コマンドが終了したあとに実行されるシステムのシャットダウン時やユーザーがサービスを停止したときに stop コマンドを実行させたいなら、
RemainAfterExit=yesを設定する必要があるExecStopは実質的に「サービス終了用」のイベントというより、「クリーンアップ時点」のイベントに近いsystemd はデーモンに合わせて作られている点を覚えておく必要がある
サービスがいつか終了するコマンドを1つ実行するだけなら、systemd にデーモンとは違う扱いをするよう明示しなければならない
ほかの人も言っているように、おそらく
oneshot+RemainAfterExitが望んでいる組み合わせである可能性が高いtype=forkingでは ExecStop は期待どおりに動作する本当に気に入った
具合が悪くなるまで純粋なコマンドラインだけを使っていたが、最近
lazygit/lazydockerのようなツールで、不透明なシステムやツリーの状態を覗き見るようになって、生産性が大きく上がったユーザーおよびシステムレベルのサービスを複数管理しているが、デバッグは退屈だ
最初の文で、よく使うコマンドとその不便さを列挙している部分が本当に刺さった
NixOS なので不変の unit ファイルを直接編集する方法は使えないだろうが、サービスの探索・可視化・管理には大いに役立ちそう
ドキュメントに「ガイド」を追加する予定だが、要約すると 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 簡単かもしれない
いずれにせよ issue を開いてくれれば見てみる
リモートサーバーや 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 を初心者にやさしくアクセスしやすいものにすることは、彼らの資金提供においてそれほど重要ではないようです
セキュリティはどう扱われていますか？
Linux がうまく処理しているシステム権限の話ではなく、外部の攻撃者に乗っ取られて リモート制御されないという保証があるのかが気になります
sudoで何かを行うアプリケーションやスクリプトを実行するときに、自分自身に問うべき重要な質問だと思いますそのため isd のドキュメントページに、かなり詳しい Security セクションを書いてあります
https://isd-project.github.io/isd/security/
足りない点があれば教えてもらえるとうれしいです