systemd：htop用のgettyのようなサービス

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で簡単なスクリプトを作成します。

 #!/bin/bash echo "Press a key to launch $(basename "$1")" read exec "$@"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼がすることは、入力を待って、ある種のプログラムを開始することだけです（この場合は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)



ます。

 #!/bin/bash echo "Press a key to launch $(basename "$1")" read exec su -c "$@"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サービスのインストール

これでサービスの準備が整いました。起動に追加するだけです。

 $ 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のごく一部に影響します。 頑張って！