CentOS7は、その親であるRHEL7と同様に、SysVおよびLSB初期化スクリプトと互換性のあるLinux用のシステムおよびサービスマネージャーであるsystemdを使用します。 systemdは、積極的な並列化機能などを提供します。
![画像](https://habrastorage.org/files/144/e73/f6a/144e73f6a1624bc3a88dc2505ff6ca69.png)
多くの機能、柔軟な設定、およびメガバイトのドキュメントを備えた巨大なモンスター...
しかし、昨日、タスクが高速で高速で、何らかのサービスを自動開始する場合はどうでしょうか?
ドキュメントから最低限必要な情報を絞り込んで、簡単な開始停止スクリプトを作成しましょう。
Systemdは、その構成で説明されているサービスを開始します。
構成は多くのファイルで構成され、ファッショナブルにユニットと呼ばれます。
これらのユニットはすべて、次の3つのディレクトリに配置されています。
/ usr / lib / systemd / system / -インストールされたRPMパッケージのユニット-すべての種類のnginx、apache、mysqlなど
/実行/ systemd / system / -ランタイムで作成されたユニット-また、おそらく正しいこと
/ etc / systemd / system / -システム管理者が作成したユニット-ここにユニットを配置します。
ユニットは、Microsoft Windows .iniファイルに類似した形式のテキストファイルです。
[角括弧内のセクション名]
variable_name = value
単純なユニットを作成するには、[ユニット]、[サービス]、[インストール]の3つのセクションを記述する必要があります
ユニットセクションでは、このユニットについて説明します。
変数名は非常にわかりやすいものです。
ユニットの説明:
説明= MyUnit
以下は、サービスの読み込み順序に影響する変数のブロックです。
サービスまたはサービスのグループ(たとえば、network.target)の後にユニットを実行します。
後= syslog.target
後= network.target
後= nginx.service
後= mysql.service
サービスを開始するには、実行中のmysqlサービスが必要です。
必要= mysql.service
サービスを開始するには、実行中のredisサービスが望ましい:
Wants = redis.service
その結果、Wants変数は純粋に記述的です。
サービスがRequiresにあるがAfterにない場合、必要なサービスを正常にロードした後ではなく、必要なサービスと並行してサービスが起動されます
[サービス]セクションで、サービスを開始するコマンドとユーザーを指定します。
サービスの種類:
タイプ=シンプル(デフォルト):systemdは、サービスがすぐに開始されると想定します。 プロセスは分岐しないはずです。 このサービスの開始時に他のサービスがキューに入れられている場合は、このタイプを使用しないでください。
タイプ=分岐systemdは、サービスが一度開始され、プロセスが親プロセスの完了で分岐すると想定しています。 このタイプは、古典的なデーモンを実行するために使用されます。
systemdがメインプロセスを追跡できるように、PIDFile =も定義する必要があります。
PIDFile = / work / www / myunit / shared / tmp / pids / service.pid
作業ディレクトリ。起動コマンドを起動する前に現在のディレクトリになります。
WorkingDirectory = / work / www / myunit / current
サービスを開始するユーザーとグループ:
ユーザー= myunit
グループ= myunit
環境変数:
環境= RACK_ENV =本番
メモリ不足とOOMメカニズムの操作によるサービスの強制終了の禁止:
-1000の完全禁止(sshdには1つ)、-100の場合は確率が低くなります。
OOMScoreAdjust = -100
サービスチームの開始/停止およびリロード
ExecStart = / usr / local / bin / bundle exec service -C /work/www/myunit/shared/config/service.rb --daemon
ExecStop = / usr / local / bin / bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop
ExecReload = / usr / local / bin / bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart
ここには微妙な点があります-systemdはコマンドが特定の実行可能ファイルを指していると主張します。 フルパスを指定する必要があります。
秒単位のタイムアウト、システムが開始/停止コマンドで動作するまで待機する時間。
TimeoutSec = 300
systemdに、サービスが突然機能しなくなった場合にサービスを自動的に再起動するように依頼します。
監視は、PIDファイルからのプロセスの存在によって実行されます
再起動=常に
[インストール]セクションで、サービスを開始する実行レベルを説明します。
起動レベル:
WantedBy = multi-user.target
multi-user.targetまたはrunlevel3.targetは、通常のランレベル= 3「グラフィックなしのマルチユーザーモード」に対応します。 ユーザーは通常、複数のコンソールを使用して、またはネットワーク経由でログインします。
したがって、最も単純な起動スクリプトが用意されており、systemdの単位でもあります。
myunit.service
[Unit] Description=MyUnit After=syslog.target After=network.target After=nginx.service After=mysql.service Requires=mysql.service Wants=redis.service [Service] Type=forking PIDFile=/work/www/myunit/shared/tmp/pids/service.pid WorkingDirectory=/work/www/myunit/current User=myunit Group=myunit Environment=RACK_ENV=production OOMScoreAdjust=-1000 ExecStart=/usr/local/bin/bundle exec service -C /work/www/myunit/shared/config/service.rb --daemon ExecStop=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state stop ExecReload=/usr/local/bin/bundle exec service -S /work/www/myunit/shared/tmp/pids/service.state restart TimeoutSec=300 [Install] WantedBy=multi-user.target
このファイルをディレクトリ/ etc / systemd / system /に配置します
ステータスsystemctl status myunitを確認します
myunit.service - MyUnit Loaded: loaded (/etc/systemd/system/myunit.service; disabled) Active: inactive (dead)
無効になっている-許可する
systemctl enable myunit
systemctl -l status myunit
ユニットにエラーがない場合、出力は次のようになります。
myunit.service - MyUnit Loaded: loaded (/etc/systemd/system/myunit.service; enabled) Active: inactive (dead)
サービスを開始します
systemctl start myunit
美しいステータスを見てみましょう:
systemctl -l status myunit
エラーがある場合、ステータスの出力を読み取り、修正します。ユニットで修正した後、systemdデーモンをオーバーロードすることを忘れないでください
systemctl daemon-reload
さて、systemdでのトライアルダイビングの後、独立した水泳を開始できます。
急に質問がある場合は、ask @ centos-admin.ruにご連絡ください。