古いsysvinitの習慣をsystemdに移植

古いsysvinitの習慣をsystemdに移植

私は新しいDebian安定システムをインストールして設定するために使用する一連のスクリプトを持っています。私が使用するプログラムを自動的に起動するには、/etc/rc.local他の場合はファイルを手動で変更する必要があります/etc/inittab--noclear行に追加するなどの他の変更があります1:2345:respawn:/sbin/getty --noclear 38400 tty1

終了プロセスをカスタマイズする必要があるため、最終的には次のようにしました。

l0:0:wait:/etc/rc.halt 0
...
l6:6:wait:/etc/rc.halt 6

これは私の/etc/rc.halt姿です。

#!/bin/sh
#   
# rc.halt
#   
# This script is executed when entering level 6/0 (on halt or reboot)

su - teststand -c "/home/teststand/stop_server.sh"  # my custom command

# making sure the halt/reboot process is resumed
test -n "${1}" && /etc/init.d/rc ${1}

exit 0

今日は、初めてデフォルトの初期systemd化システムとして新しいDebian 8をインストールする日でした。こんなことは思わなかったけど、/etc/inittabファイルの損失があって初めて驚きました。

現在のシステム(@workと@home)はまだシステムを実行しているsysvinitのでsystemd

以前のバージョンに変更できることはわかっていますが、で動作するものが何であるsysvinitかを確認したいと思いますsystemd。また、今すぐ新しいインストールをカスタマイズしていますが、完了する時間があまりないため、インストールは完了しません。今はドキュメントを見る時間がありません。

systemd私の質問:動作をすばやく変更して追加し、--noclear再起動/停止の開始点gettyとして使用する方法はありますか?/etc/rc.halt

デフォルトでは、以前のinittab変更をすばやくインポートできますかsystemd

ありがとう

ベストアンサー1

systemdはSystem 5と互換性がなく、initSystem 5のみ互換性がありますrc

Linux System 5スタイルのシステム管理は2つの部分で構成されています。initこれはプロセス#1として実行され、起動スクリプトrcと停止スクリプトの実行を担当します。実際にはDebianの2つの異なるパッケージから来ました。 init出身ですシステムベネットパッケージrc一般的には以下で提供されます。sysv-rcパッケージですが、次から来ることもできます。ファイル-rcまたはオープンソースライブラリパック。

/etc/inittab処理された設定ファイルですinit。 systemd は、これに対する以前のバージョンとの互換性メカニズムを提供しません。 systemdのSystem 5以前のバージョンとの互換性メカニズムは、rc実行中のSystem 5にのみ適用されます/etc/init.d/。 (これはsystemdの特定のバージョンにのみ適用され、rcsystemdはfile-rcとopenrcの構成メカニズムの以前のバージョンとの互換性メカニズムを実装しません。)

これはsystemdに限定されていません。ほぼいいえinit / sysmanagerプロセスを交換します(30年に1回を除く)/etc/inittab

サービスをsystemdに接続するには、サービスが使用するメカニズムを使用する必要があります。するサポート、つまり自分のサービスユニットファイルと(自動的にユニットファイルに変換するジェネレータを介して).formatrcシステム5設定ファイル/etc/init.d/

ランレベルを忘れてください。

使用中のすべてのランレベルエントリは、システムLinuxオペレーティングシステムで「使用されていません」と宣言されています。 いいえランレベル0または6を入力できます。いくつかの互換性スペーサーがなければ存在しません。

サービスが終了したときにサービスを実行するには、サービスユニットを作成することが多くの人の当然の答えですWantedByshutdown.targetしかし、ここにはいくつかの微妙な落とし穴があります。より良いがあまり明確ではない答えは、一般的なサービスユニットを作成し、終了ターゲットとDefaultDependencies=yes競合していることを確認し、サービスのコアコンテンツExecStopExecStart

[単位]
ドキュメント=https://unix.stackexchange.com/questions/233561/

[提供する]
種類=使い捨て
ユーザー=テストベンチ
終了後の残り値=true
ExecStart=/bin/true
ExecStop=/home/teststand/stop_server.sh

[インストールする]
WantedBy =マルチユーザー。ターゲット

シェルスクリプトから貧しい人のデーモンマネージャを自分で作成しないでください。

これらの記事は常に正しく書かれていません。

「サービス」が単に「stop_server.sh」というコマンドを実行する場合、これは一部の手動シェルスクリプトサービス管理システムでサーバーを停止するスクリプトであると推測できます。

正しく作成されておらず、不安定で信頼できず、危険な災害についてのみ:stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh

あなたは体系化しました。 これを活用し、ここで実行されるすべてのサービスに適切なサービス管理メカニズムを使用します。ExecStop必要に応じて、この奇妙なサービスはまったく必要ありません実際DefaultDependencies=trueサービスは、次のようにsystemdを介して実行できます。systemd がサービス終了を処理する終了時間中。

1つのサービスを「管理」するために、シェルスクリプトに貧しい人のデーモン監督者を雇い、それをシステムサービス単位でラップして2番目のサービスを提供し、終了時にそのサービスを開始する準備をするだけです。最初のサービス管理そして、システムが停止またはシャットダウンしたときにシステムをシャットダウンすることは、システム化された恐怖の家に入るための良い方法です。

世界はあなたが画面をきれいにしたいです。

〜したいいいえGreg Wooledgeと他の人が見つけたように、ログアウトとその後のログインの間に仮想端末を消去することは、実際に傾向に反することです。特権ユーザーまたは上司がログアウトした後も持続する機密出力は、1970年代からUnices(および実際には別の時分割リモートアクセスオペレーティングシステム)のセキュリティ上の問題であり、これらのすべての出力を取り消すにはかなりの努力が必要です。この問題を避けるために人々が置いたもの。

  • 多くのシステムでは、clear_consoleシェルログアウトスクリプトに標準コマンドがあります。 (カーネル仮想端末#1で実行されるグラフィックプログラムではうまく動作せず、他の種類の端末(仮想または実際)では動作しないため、これ自体が問題になります。)

    このコマンドは削除する必要があります。

  • たとえば、仮想端末を対象とするgettyプログラムのデフォルト設定は、端末を消去することmingettyです。 (ログインする前にこれを行います。つまり、TTYログインサービスが停止してもターミナル出力が変わらない可能性があります。皮肉なことに、loginPAMの必要性のおかげでより良い場所に配置できますが、ログアウトしても実行されます中です。

    --noclearこの機能を無効にするには、このオプションを展開する必要があります。これには、ファイルを上書きしたり、設定を変更したりExecStart、単に[email protected]自分が設計したローカルユニットファイルを指す1つ以上のユニットファイルを作成することが含まれます。

  • systemd が提供する[email protected]テンプレートサービスユニットセットは、TTYVTDisallocate=yessystemd にカーネル仮想端末をクリアするよう指示します。 (これは名前が部分的に反映されるため、ユーザー空間の仮想端末を含む他の種類の端末では機能しません。)

    また、上書きまたは指定された他のサービステンプレートを使用して再度削除する必要があります[email protected]

追加読書

おすすめ記事