CentOS / RHELでサービスとスクリプトの自動起動を管理する方法
この記事では、Linux CentOS/RHEL 7/8においてサービスやスクリプトをシステム起動時に自動的に開始させるための基本設定方法を解説します。特にsystemdデーモンの概要をはじめ、サービスをスタートアップに追加・削除する方法、そしてLinuxで起動時にスクリプトやデーモンを実行するための代替手段についても取り上げます。
この記事を通じて、Linuxで自動起動されるサービスやスクリプトの一覧を素早く確認する方法、独自のサービスやスクリプトをスタートアップへ追加する方法、特定アプリケーションの自動起動を無効化する方法を習得できることを目指します。
systemctlを使ったsystemdサービスの管理
主要なLinuxディストリビューション(CentOS、RHEL、Debian、Fedora、Ubuntu)では、従来のinit.dに代わってsystemdが起動デーモンとして採用されています。Systemdは、他のデーモンを起動し管理するためのLinuxサービスマネージャーです。/etc/systemd/system配下のユニットファイルを使用します(旧init.dは/etc/init.d/内のスクリプトを使用していました)。systemdはOS起動時のサービス起動処理を並列化できる点も特徴です。
systemdを操作するには、systemctlコマンドを使用します。
まず、システム起動後にsystemdで利用可能なユニットの一覧を確認してみましょう。
systemctl list-units

ユニットファイルの一覧は次のコマンドで取得できます。
systemctl list-unit-files
このコマンドにより、利用可能なすべてのユニットファイルが表示されます。
稼働中のサービスとその状態の一覧を表示するには、以下のコマンドを実行します。
# systemctl list-units -t service
一部のユニットは起動プロセス完了後に非アクティブになる場合があるため、--allオプションを付ければ完全な一覧を取得できます。
# systemctl list-units --all
UNIT LOAD ACTIVE SUB DESCRIPTION proc-sys-fs-binfmt_misc.automount loaded active waiting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ● exim.service not-found inactive dead exim.service firewalld.service loaded active running firewalld - dynamic firewall daemon getty@tty1.service loaded active running Getty on tty1 ● iptables.service not-found inactive dead iptables.service Bring up/down networking ● NetworkManager-wait-online.service not-found inactive dead
この一覧を見ると、ディスク上に存在しないサービスまで表示されていることが分かります。
その他にも便利なオプションがあります。
- --state — デーモンの状態(Load、Active、Sub)を指定して絞り込む
- --type — ユニットの種別でフィルタリングする
使用例:
systemctl list-units --all --state=active — アクティブなsystemdユニットのみ表示
systemctl list-units --type=service — サービスタイプのユニット一覧を表示

systemdでサービスを作成するには?
systemdでサービスを扱う際は専用の記法が必要です。サービス名の末尾に必ず.serviceを付けます。例:
# systemctl enable nginx.service — nginxウェブサーバーをスタートアップに追加するコマンドです。
このコマンドを実行すると、systemdのスタートアップディレクトリ内に、指定されたサービスファイルへのシンボリックリンクが作成されます。
# systemctl enable nginx.service
Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service
出力には、サービスファイルへのシンボリックリンクが作成されたディレクトリが表示されます。
サービスがスタートアップに登録されたかどうかは、ステータスを確認することで判別できます。
systemctl status nginx.service
出力中の以下の行に注目してください。
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
enabledという値は、そのサービスがLinuxの起動時に自動的に開始されるよう登録されていることを意味します。自動起動が無効の場合はdisabledと表示されます。
systemdでサービスを無効化するには?
サービス自体を削除せずに、Linux起動時に自動的に開始されないようにすることも可能です。サービスの自動起動を無効にするには、次のコマンドを実行します。
# systemctl disable your_service
例えばnginxの自動起動を無効化する場合は:
# systemctl disable nginx.service
Removed symlink /etc/systemd/system/multi-user.target.wants/nginx.service
これにより、systemdディレクトリからサービスファイルへのシンボリックリンクが削除されます。自動起動の状態は以下のコマンドで確認できます。
# systemctl is-enabled nginx
systemdでユニットをマスクするには?
無効化してもスタートアップに残り続け、Linux再起動後にまた起動してしまう厄介なサービスに出会うことがあります。この問題への対処法として、サービスを「マスク」できます。
# systemctl mask nginx.service
マスクされると、手動での起動もOS再起動後の自動起動もできなくなります。
# systemctl mask nginx.service
Created symlink from /etc/systemd/system/nginx.service to /dev/null.
# service nginx restart
Redirecting to /bin/systemctl restart nginx.service Failed to restart nginx.service: Unit is masked.
マスクを解除するには次のコマンドを使用します。
# systemctl unmask nginx.service
Removed symlink /etc/systemd/system/nginx.service.
マスク後にユニットファイルの一覧を確認すると、該当サービスがmaskedとして表示されます。

rc.localでスクリプトやサービスを実行する
Linux起動時に各種スクリプトを実行したい場合、rc.localがよく使われます。
rc.localではスクリプトだけでなく、サービスの実行も可能です。systemdで管理されているサービスさえ実行できます。systemdがあるのにわざわざrc.localを使う理由はないかもしれませんが、いくつか例を挙げておきます。
まず、/etc/rc.localに実行権限を付与する必要があります。
chmod +x /etc/rc.local
rc.localをsystemdの自動起動に登録します。
systemctl enable rc-local
あとはnginxウェブサーバーの起動コマンドをrc.localに追記すればOKです。
service nginx start

ただし、私自身はサービスの起動にrc.localを使うことはあまりありません。むしろrc.localは、スクリプトの実行や一回限りのコマンド実行に使われることが多いでしょう。
例えば、何らかの処理を行うスクリプト/root/test.shを作成し、起動直後に実行したいとします。rc.localファイルに以下の行を追記します。
sh /root/test.sh

CentOS 7以降では、開発者側がrc.localを廃止予定のレガシー機能と位置づけており、スクリプトやサービスの起動用途での使用は推奨されていません。とはいえ、動作し続けている間はそのシンプルさゆえに使い続ける価値はあります。
systemdで独自のLinuxサービスを作成する方法
独自のデーモンを作成し、systemd経由で管理することもできます。
例えば、先ほどのスクリプト(/root/test.sh)をシステム再起動のたびに毎回実行したいケースを考えます。まず新しいサービスのユニットファイルを作成しましょう。
touch /etc/systemd/system/test-script.service
chmod 664 /etc/systemd/system/test-script.service
nano /etc/systemd/system/test-script.service
ファイルの中身は以下のように記述します。
[Unit] Description=Template Settings Service After=network.target [Service] Type=oneshot User=root ExecStart=/root/test.sh [Install] WantedBy=multi-user.target
主なパラメータの意味は次の通りです。
User – デーモンを起動するユーザーアカウント
Type=oneshot — プロセス終了を待ってから、他のユニットの処理に進むことをsystemdに指示する
設定を反映してテスト実行します。
# systemctl daemon-reload
# systemctl start test-script.service
# systemctl status test-script.service
● test-script.service - Test Loaded: loaded (/etc/systemd/system/test-script.service; disabled; vendor preset: disabled) Active: active (running)
問題なく動作していれば、systemdのスタートアップに登録します。
# systemctl enable test-script.service
Created symlink from /etc/systemd/system/multi-user.target.wants/test-script.service to /etc/systemd/system/test-script.service.
この方法なら、任意のスクリプトを自動起動に組み込み、systemd経由で一元管理できます。
cronでスクリプトを実行する方法
ある頻度で定期的にスクリプトやコマンドを実行したい場合は、cronを活用します。
crontab -e — cronタスクの編集エディタを開きます
ここに実行したいタスクを追記します。例:
* * * * * /root/test.sh — 毎分1回スクリプトを実行する設定
さらに、サービスの稼働状態を監視し、停止していたら自動的に再起動するウォッチドッグスクリプトを作成することも可能です。私自身も一部のプロジェクトで同様の手法を利用しています。
cronに登録済みの全タスク一覧を表示するには:
# crontab -l
* * * * * /root/test.sh
cronタスクの実行タイミングとして指定できる時間フィールドは、左から順に以下の通りです。
- 分: 0〜59
- 時: 0〜23
- 日: 1〜31
- 月: 1〜12
- 曜日: 0〜7(0または7は日曜日)
今回のタスクは毎分実行のため、すべてのフィールドにアスタリスク(*)が入っています。
また、スクリプトをcron専用ディレクトリのいずれかに配置する方法もあります。
- /cron.daily — 毎日1回実行するスクリプト向け
- /cron.hourly — 毎時1回実行するスクリプト向け
- /cron.monthly — 毎月1回実行するスクリプト向け
- /cron.weekly — 毎週1回実行するスクリプト向け
これらのディレクトリに置かれたスクリプトは、それぞれのスケジュールに従って自動実行されます。
Bash起動スクリプト: .bashrc
SSHコンソール起動時に特定の処理を実行したい場合は、任意のコマンドやスクリプトを.bash_profileまたは.bashrcファイルに追加します。理論上はどちらのファイルに書いても実行されますが、一般的には必要な処理を.bashrcに記述し、.bash_profileから.bashrcを読み込む構成にします。
試しに、nginxウェブサービスを再起動するコマンドを.bashrcに追加してみます。
service nginx restart

ファイルを保存し、SSHセッションを再接続すると:

ご覧の通り、ターミナル起動時にウェブサーバーも一緒に再起動されました。ターミナル起動時に実行できる処理は他にもあります。例えばuptimeによるサーバー稼働時間チェックなどの補助ツール表示も便利です。

SSHコンソール起動時に特定ディレクトリへ移動しmc(Midnight Commander)を起動したい場合は、.bashrcに以下を追記します。
cd /var/
mc

この記事が、Linuxにおけるサービスやスクリプトの起動管理の理解に役立てば幸いです(本記事はCentOSおよびRHEL向けに執筆しましたが、他のディストリビューションでも応用可能です)。Linuxシステム管理の基礎を学んでいる方にとって、ここで紹介した情報はきっと役立つはずです。
-
ERD Commander AutorunsでWindowsのスタートアッププログラムを管理・最適化する方法
かつて、ソフトウェアはスタートメニューの「スタートアップ」フォルダに項目を追加したり、レジストリのRunキーに値を書き込んだりすることで自動起動していました。しかし近年では、悪質なスパイウェアやアドウェアを配布する企業が、ブラウザヘルパーオブジェクト(BHO)、サービス、タスクスケジューラ、さらにはイメージファイルなどを利用してソフトウェアを自動的に読み込む手法を編み出しています。 これらすべての箇所を手作業で一つずつ確認するのは、時間がかかるだけでなく、一般ユーザーにはほぼ不可能な作業です。自動起動するプロセスを管理するためのツールとしては、「MSConfig」「CCleaner」「タスクマ
-
Windows 10のスタートアップアプリを管理する方法|PCの起動を高速化する完全ガイド
Windows 10は高速でレスポンス性に優れたOSですが、パソコンの起動時に多数のアプリやサービスが自動的に立ち上がる設定になっていると、起動プロセスが大幅に遅くなってしまいます。これらの自動起動プログラムの多くは便利なものである一方、システムリソースを消費し、起動時間を長引かせる原因にもなります。 スタートアップアプリが問題になる理由 すべてのパソコンには、電源を入れたときに(自動または手動で)起動するように設定されたプログラムやアプリの一覧が存在します。これらは起動時間を長くするだけでなく、バックグラウンドで動き続けるため、システム全体のパフォーマンスにも悪影響を及ぼします。 この現象が