htopは対話型プロセス監視プログラムです。 彼女はトッププログラムの代替です。 Linuxマシンの背後で働くすべての人が、それを少なくとも1回は使用しています。プロセス（およびその後の強制終了）を検索しているか、使用されているリソースを注意深く監視しているかです。
便宜上、このプログラムは常に実行し続けることができます：別のターミナルウィンドウ、タブ、またはデスクトップで。 ただし、別の解決策があります。固定VTで実行し、いつでも切り替えることができます。 このアプローチの利点は、クリーンな環境とX /端末からの独立性です。
htop用の特別なgettyのようなサービスを実際に取得したいので、初期化システムを使用してこれを行うことができます（そして正しい）。
VT1、...、VT6はどのように起動しますか？
agettyは、ttyポートを開き、認証のプロンプトを発行し、その後の制御を別のプログラムlogin転送するプログラムです。
$ which agetty login | xargs ls -l -rwxr-xr-x 1 root root 44104 Sep 29 05:21 /usr/bin/agetty -rwxr-xr-x 1 root root 35968 Sep 29 05:21 /usr/bin/login
従来のLinux初期化システムは、ブート時に一定量のagettyを実行するように構成されています。 ほとんどの場合、6つのVT（tty1からtty6まで）に対して6つのインスタンスが作成されます。 Systemdは異なるアプローチを取ります。
- 最初は動的です。
getty@.service .serviceサービスgetty@.serviceオンデマンドgetty@.service開始されgetty@.service 。 つまり、特定のVTが必要な場合のみです。 Logindがこれを担当し、ttyNに切り替えるとautovt@ttyN.serviceサービスを開始します。これはgetty@.serviceシンボリックリンクgetty@.service 。 このロジックはtty2-tty6で機能します。 - 2番目は静的です。
getty@.serviceの特定のインスタンスは、 getty@.serviceを介して自動的に撤回され、常にtty1でgettyを実行できます。
systemctl cat getty@.serviceは、このサービスの内容を表示します。 これは私たちにとってそれほど重要ではないため、詳細に検討するつもりはありません。
したがって、特定のhtop@.serviceがあると仮定した場合、 htop@.serviceという名前でシンボリックリンクを作成するか、選択したVTに切り替えると、gettyの代わりにhtopが起動するか、無効にするか、2つの方法でautoloadに追加できますgetty@ttyN.serviceを含める-これにより、常に固定VTでhtopを実行できます。
独自のgettyのようなユニットを作成する
ここで、 /etc/systemd/systemユニットが配置されているディレクトリの1つ）に移動し、独自のサービスを作成します。
$ "$EDITOR" htop@.service
サフィックス（ @ ）が存在するということは、サービス自体ではなく、そのインスタンスの1つが開始されることを意味します。 そして、接尾辞はパラメータメーター（ %iおよび%I ）で渡されます。
getty@.serviceコンテンツは、私たちにとってそれほど重要ではないことは既に上で述べました。 私たちのサービスに含めることができるので、そうです：
.include /usr/lib/systemd/system/getty@.service
サービスがgettyに似ていることを考えると、この構造は不必要なコードのコピーから私たちを救います。
ユニットセクション
任意のタイプのユニットに適用可能な一般的なパラメーターについて説明します。
[Unit] Description=htop on %I Documentation=man:htop(1)
ここではすべてが透過的ですDescriptionディレクティブはユニットの短い説明を設定し、 Documentationへのパスです。 %Iはインスタンスの名前です。 インスタンス名を指定する両方の変数の値が異なることに注意することが重要です： %Iは%iと同じですが、エスケープをエスケープしません。
サービス部門
このセクションでは、サービスを具体的に構成します。 つまり、プロセスを開始する方法を説明します。
[Service] Environment= Environment=TERM=linux HOME=/root ExecStart= ExecStart=/usr/bin/htop StandardInput=tty-fail StandardOutput=tty
必要なディレクティブの継承された値はそのままにして、一部をリセット（空の値を設定）し、自分で定義する必要があります。 これらには、 Environment設定-変数の設定、およびExecStart実際にプロセスを開始することが含まれます。
StandardInput=tty-fail StandardOutput=tty
-これは、端末に直接接続されたhtopを起動するsystemdの表示です。
ところで、インスタントスタートを追加するのではなく、入力を期待して追加することができます。 これを行うには、bashで簡単なスクリプトを作成します。
彼がすることは、入力を待って、ある種のプログラムを開始することだけです（この場合はhtopになります）。 任意の場所に配置し、任意のExecStartて実行可能にし（ chmod +x ）、サービスのExecStartを編集します。
ExecStart=/etc/systemd/scripts/run_wait /usr/bin/htop
制限権
もちろん、権利に何らかの制限を課す必要がある場合は、これを行う必要があります。 これを行うために、別のサービスと別のスクリプトを作成します。現在はhtop_secure@.serviceとrun_wait_suです。 htopが特定のユーザーと特定のグループの権限で起動し、管理者パスワードも必要になるように、それらを再構成します。
したがって、前の2つのサービスに基づいて新しいサービスと新しいスクリプトを作成します。
$ cd /etc/systemd $ cp system/htop@.service system/htop_secure@.service $ cp scripts/run_wait scripts/run_wait_su
そして、それぞれを編集します。 [サービス]セクションのサービスについて、[環境]の値を変更し、グループでユーザー名を設定します。
User=kalterfive Group=users Environment=TERM=linux
スクリプトでは、 su(1)ます。
サービスのインストール
これでサービスの準備が整いました。起動に追加するだけです。
$ systemctl daemon-reload $ systemctl disable getty@tty2.service $ systemctl enable htop@tty2.service
最初のコマンドはsystemd構成マネージャーを更新し、2番目のコマンドはgetty.target.wantsサービスへのシンボリックリンクを作成します。
おわりに
次に、リブート（または手動でtty2インスタンスのgetty@をhtop@してhtop@をオンにします）し、2番目のVTに切り替えて、正常に起動したhtopを確認します。 実証されたトリックは、初期化システムとして、その機能の全範囲から、普遍的な配管層として、完全に異なる問題を解決するためのプログラムのセットとして、systemdのごく一部に影響します。 頑張って！