バックグラウンドまたは起動時にサービスを管理する方法を知りたいですか?
起動時にプロセスを管理および開始するメカニズムが変更されました。 RHEL/CentOS 6.x までは、/etc/init.d/ にスクリプトを作成し、
chkconfig
を使用して有効にしていましたが、
RHEL 7
では状況が異なります。
これは
systemd
に置き換えられ、Linux のメジャー バージョンでは多かれ少なかれデフォルトのプロセス マネージャーであるため、他の種類に精通したシステム管理者にとっては安心できるでしょう。この記事では、
systemd
とは何か、切り替えの理由、そして
systemd
を使用してバックグラウンド プロセスをセットアップ、実行、管理する方法について説明します。

システム化とは何ですか?
Linux のすべてのプロセスは透過的に表示されるので、
systemd
がどこに潜んでいるか見てみましょう。私のシステムでは次のような結果が得られます。
~$ ps -ef | grep systemd
root 1 0 0 Nov11 ? 00:01:02 /lib/systemd/systemd --system --deserialize 22
message+ 768 1 0 Nov11 ? 00:05:46 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
root 805 1 0 Nov11 ? 00:10:22 /lib/systemd/systemd-logind
ankush 1132 1 0 Nov11 ? 00:00:00 /lib/systemd/systemd --user
ankush 1176 1132 0 Nov11 ? 00:04:50 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
ankush 9772 20029 0 21:11 pts/6 00:00:00 grep --color=auto systemd
systemd+ 17298 1 0 Nov19 ? 00:00:12 /lib/systemd/systemd-resolved
systemd+ 17303 1 0 Nov19 ? 00:00:00 /lib/systemd/systemd-timesyncd
root 17307 1 0 Nov19 ? 00:00:02 /lib/systemd/systemd-journald
root 18182 1 0 Nov19 ? 00:00:00 /lib/systemd/systemd-udevd
きっとすぐに気づいたんだと思います。リストの最初のプロセスはユーザー
root
として起動され、pid は 1 です。
案の定、これはシステムの起動時に起動される最初のプロセスでした。
systemd
に挨拶します。 🙂
したがって、非常に簡単に言うと、
systemd
、システム内の他のプロセスを起動、管理、終了する「マザー」プロセスであり、ログやファイルシステムのステータスなどに関する情報を提供します。
ただし、名前についてのメモ。名前は確かに
systemd
であり、System D などではありません。 「d」はデーモンを表します。デーモンは、バックグラウンドで動作 (潜伏?) し、どのターミナル セッションにも接続されない標準 Linux プロセスです。

RHEL が systemd に切り替えた理由は何ですか?
すでに説明したように、systemd はシステムおよびプロセス マネージャーであり、RHEL 7 ではよく知られたプログラム Upstart を置き換えます。なぜ RHEL はこの決定を下したのでしょうか?これには十分な理由があるので、簡単に見てみましょう。
並列サービスの初期化
SysV
init
プログラムとは異なり、
systemd
はサービスを並行して起動できます。対照的に、
init
プログラムはそれらを 1 つずつ起動します。モバイル デバイスにもマルチコア CPU が搭載されている時代において、並列初期化の欠如は大きな問題です。
動的(ホット)サービス管理
USB ドライブは、Ubuntu や同様のディストリビューションでは自動的に開くのに、以前の Fedora システムでは明示的にマウントする必要があることに気づいた場合、その理由は
systemd
にあります。ハードウェアのライブ変更を検出し、必要に応じてサービスを終了/起動できます。それは不必要だと主張する人もいますが、多くの人にとって、認知的負担を軽減するものは大歓迎です。
サービス開始の延期
systemd
、サービスの起動を実際に必要なときまで遅らせることができるため、起動時間を短縮します。簡単な例としては、ネットワーク ファイル システム関連のサービスがあります。ネットワークに接続されたディスクが利用できない場合、サービスを稼働させても意味がありません。
プロセス通信の高速化
systemd
の並列機能はプロセス間通信にも引き継がれます。
systemd
ソケットとシステム バスへの並列アクセスを提供できるため、通信リソースのプロセス待機時間を大幅に短縮できます。
自動再起動
サービスがクラッシュした場合、
systemd
それを検出し、再起動を試みます。ほとんどの場合、より根本的な問題がない限り、アプリケーションが再び機能し始めるために必要なのは、単純な再起動だけです。
とにかく、
systemd
システム管理者の作業を楽にしてくれます。

RHEL7 の systemd – システム管理者にとっての変更点?
systemd
すべての機能を備えたものになるわけではないと感じているのなら、それは正しいことです。 RHEL sysadmin に不意を突かれる可能性のある重大な非互換性がいくつかあります。早速見てみましょう。
限定的なランレベルのサポート
systemd
のランレベルの認識とサポートはかなり不十分です。すべてのランレベルがサポートされているわけではなく、一部のターゲットではサポートされていない場合もあります。このような場合、
systemd
runlevel
コマンドへの応答として「N」を返し、このターゲットに対応するランレベルがないことを示します。全体として、Red Hat は
runlevel
コマンドを使用しないように (!) アドバイスしています。
カスタムコマンドはありません
こっちは傷つくよ。 SysV の大きな利点の 1 つは、プロセスを管理するためのより優れた機能を提供するカスタム コマンドを定義できることです。
systemd
ではそのようなオプションはなく、
start
、
stop
、
status
、
restart
などで立ち往生します。
家族限定で非インタラクティブ
systemd
(もちろん) 起動したプロセスを追跡し、その PID を保存します。ただし、課題は、
systemd
起動していないプロセスを systemd が処理できないことです。さらに、ユーザーは
systemd
によって開始されたプロセスと対話することはできません。すべての出力は
/dev/null
に送られるため、出力をキャプチャするという期待は実質的になくなります。
文脈がありません
init
サービスとは異なり、
systemd
によって起動されるサービスは、システム内のユーザーから環境を継承しません。つまり、
PATH
やその他のシステム変数などの情報は利用できず、すべての新しいプロセスは空のコンテキストで起動されます。
この制限のリストを見て泣きそうになったとしても、繰り返しますが、あなたは一人ではありません。
systemd
Linux の世界で二極化する勢力であり、「systemd 最悪」でグーグル検索すると、たくさんの読み物が見つかります。 😉
ダウン時にサービスを自動的に開始するにはどうすればよいですか?
デプロイメントにおける非常に一般的な使用例を次に示します。長時間実行されるプロセスを持たない言語、つまり PHP でプログラムをデーモン化する必要があります。受信 WebSocket 接続を処理するための PHP スクリプトを作成し (結局のところ、チャット アプリを構築しました!)、そのスクリプトが
/home/ankush/chat_server/index.php
に配置されていると仮定しましょう。
WebSocket 接続はいつでもサーバーにアクセスできるため、このプロセスは常に稼働しており、受信接続を監視する必要があります。 WebSocket はステートフル接続であり、スクリプトが終了すると接続はリストになるため、ここでは従来の PHP ライフサイクルを使用できません。とにかく、WebSocket で十分です。
systemd
を介してこのスクリプトをデーモン化する方法を見てみましょう。
すべての
systemd
サービスは /etc/systemd/system に存在するため、そこに WebSocket サーバー スクリプトを記述するファイルを作成しましょう。 root ユーザーとしてログインしていると仮定します。
# vi /etc/systemd/system/chat_server.service
そして次のものが必要になります。
[Unit]
Description=Chat Server Service
After=network.target
[Service]
Type=simple
User=ankush
ExecStart=php /home/ankush/chat_server/index.php
Restart=on-abort
[Install]
WantedBy=multi-user.target
ファイルを保存し、次のステップでは systemd デーモンをリロードします。
# systemctl daemon-reload
そして、作成したばかりのサービスを開始するには、次のようにします。
# systemctl start chat_server
エラーが表示されなければ、それで完了です。
ファイル内のさまざまなディレクティブが何を意味するのかも簡単に見てみましょう。
-
[Unit]
部分は、systemd
の新しいサービス ユニットを定義します。systemd
用語では、すべてのサービスはサービス ユニットと呼ばれます。 -
After
ディレクティブは (予想通り) ネットワーキング サービスが起動された後にのみこのサービスを起動するようにsystemd
に指示します (そうでなければ、ソケット接続の下位レベルの処理は誰が行うのでしょうか?!)。 -
Type=simple
、このサービスがそれ自体をフォークしないことをsystemd
に伝えます。つまり、常に 1 つのインスタンスのみが実行されます。 -
User=ankush
、このサービスがユーザー「ankush」として実行されることを意味します。これを「root」に変更することもできますが、セキュリティの観点からはあまりお勧めできません。 -
ご覧のとおり、
ExecStart
は実際に実行するコマンドです。 -
Restart=on-abort
サービスが中止されたときにサービスを再起動する必要があることを意味します。 PHP では、長時間実行されるプロセスによってメモリがリークされ、最終的には爆発するため、これが必要になります。 -
WantedBy=
ディレクティブは、このサービスがどのターゲット (グループを考える) に属しているかをsystemd
に伝えます。これにより、そのターゲット内にサービスを指すシンボリック リンクが作成されます。
一般に、RHEL 7 で
systemd
を使用してバックグラウンド プロセスを実行するには、これで十分です。
再起動ロジックの追加オプション
上の例では、
Restart=on-abort
を構成しましたが、これが唯一のオプションではありません。他にもありますので、要件に基づいて選択してください。
- 失敗時 – 終了コードまたはシグナルがクリーンでない場合に再起動されます。
- 常に – クリーンまたはクリーンな信号がダウンしていることが判明したら再起動します
- on-abnormal – 汚れた信号、ウォッチドッグ、またはタイムアウト
- 成功時 – クリーンなシグナルまたは終了コードによって停止された場合のみ
起動時にサービスを開始するように構成する
スクリプトに満足し、動作することを確認したら、次に起動時にトリガーされるように設定します。
/etc/systemd/system に移動し、以下のenableコマンドを実行します(.serviceファイル名を自分のものに変更することを忘れないでください)
# systemctl enable chat_server.service
シンボリックリンクが作成されたことを確認するメッセージが表示されます。
Created symlink from /etc/systemd/system/multi-user.target.wants/chat_server.service to /etc/systemd/system/chat_server.service.
サーバーを再起動すると、起動時にサービスが開始されるのが確認できるはずです。
それは簡単でした!そうじゃない?

ヘルプ!私は Upstart に多額の投資をしています。 🙁
あなたが私を信頼していることは理解しています、あなたのケースは例外ではなく標準です。 RHEL は長い間 Upstart を使用してきたため、この切り替えはほとんど裏切られたように感じられます。でもまあ、制度は変わり続けるのですから、些細なことで口論するべきではありません。 Red Hat は、多くの人が古いバージョンに行き詰まっていることを認識しており、必ず参照する必要がある 移行ガイドを 作成しました。
これらすべてにおける救いの 1 つは、
systemd
が SysV
init
スクリプトと互換性があることです。そのため、ほとんどの場合、ファイルを移動するだけで同じサービスを実行できるようになります。
Linux の管理とトラブルシューティングについて詳しく知りたいですか?この オンラインコース をチェックしてください。
