まだ rc.local が必要ですか?
このステップバイステップガイドでは、従来のファイルを作成する方法を学習します。 rc.local 一般的なLinuxディストリビューションでは、 ウブントゥ、 セントOS そして アルマリナックス 起動時に必要なスクリプトまたはコマンドを有効にして実行します。.
それでも システムド デフォルトのinitとして一般的になってきた。 rc.local 起動時に短いスクリプトを素早く簡単に実行するのに、今でも便利です。以下に、方法、例、セキュリティのヒント、そして最新の代替手段をご紹介します。.
Ubuntu (18.04、20.04、22.04以降)でrc.localを有効にする
新しいUbuntuリリースでは システムド rc.local は以下のように有効化できます。一般的な手順としては、ファイルの作成、権限の設定、systemd との互換性のためのユニットの作成と有効化などがあります。.
一般的な手順
- ファイルを作成 /etc/rc.local そして、必要なシバンとコマンドを追加します。.
- ファイルへの実行権限を付与します。.
- systemd に rc.local ユニットを作成または有効にします (存在しない場合)。.
- サービスの読み込み、アクティブ化、およびステータスの確認。.
サンプルファイルの例 /etc/rc.local （いつも最後に） 出口0 場所）：
#!/bin/bash
# Example: start Docker container named myapp
docker start myapp || docker run -d --name myapp myimage
# simple sysctl
/sbin/sysctl -w net.ipv4.ip_forward=1
exit 0次に権限を設定します。
sudo chmod +x /etc/rc.local対応するユニットが存在しない場合は作成します。
sudo tee /etc/systemd/system/rc-local.service > /dev/null <<'EOF'
[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local
After=network.target
[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOFそして最後に:
sudo systemctl daemon-reload
sudo systemctl enable rc-local.service
sudo systemctl start rc-local.service
sudo systemctl status rc-local.service
sudo journalctl -u rc-local.service -b
CentOS 7/8およびAlmaLinux 8/9でrc.localを有効にする
RHELベースのディストリビューションには異なるパスがあります。従来のパスは通常 /etc/rc.d/rc.local 一般的な手順は Ubuntu と似ていますが、SELinux パスと注意事項に注意してください。.
一般的なルート
- /etc/rc.d/rc.local 従来のパスは RHEL/CentOS です。.
- 一部のシステムでは、リンクは /etc/rc.local 存在する。.
アクティベーション手順（CentOS / AlmaLinux）
ファイルの作成/編集:
sudo nano /etc/rc.d/rc.local
#!/bin/bash
# Example: mount NFS or start a container
mount -a
/usr/bin/my-startup-script.sh &
exit 0執行ライセンス:
sudo chmod +x /etc/rc.d/rc.localユニットが存在しない場合は作成します。
sudo tee /etc/systemd/system/rc-local.service > /dev/null <<'EOF'
[Unit]
Description=/etc/rc.d/rc.local Compatibility
ConditionPathExists=/etc/rc.d/rc.local
After=network.target
[Service]
Type=forking
ExecStart=/etc/rc.d/rc.local start
TimeoutSec=0
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOFその後：
sudo systemctl daemon-reload
sudo systemctl enable rc-local.service
sudo systemctl start rc-local.service
sudo systemctl status rc-local.service
sudo journalctl -u rc-local.service -bsudo restorecon -v /etc/rc.d/rc.local
# or temporarily change context
sudo chcon -t bin_t /etc/rc.d/rc.local次のようなスクリプトでは絶対パスを使用する方が良いでしょう。 /usr/bin/docker PATH への依存を減らすために使用します。.
実践的な例と実践的なヒント
例 - Dockerランチャースクリプトの実行
#!/bin/bash
# start redis container at boot
/usr/bin/docker run -d --name redis-cache --restart unless-stopped redis:6
exit 0注記： オプションを使用する --停止していない限り再起動 Docker がコンテナのロールバックを処理するようにします。.
例 - サービスを実行する前にネットワークマウントする
スクリプトに NFS マウントが必要な場合は、適切な依存関係で systemd ユニットを変更します。
[Unit]
After=network-online.target remote-fs.target
Wants=network-online.target remote-fs.target長いスクリプトや永続的なサービスを実行する - より良い方法
長時間実行されるタスクやサービス指向のタスクの場合は、再起動や監視などの機能を使用するために専用の systemd ユニットを作成することをお勧めします。
sudo tee /etc/systemd/system/myjob.service > /dev/null <<'EOF'
[Unit]
Description=My Long Running Job
After=network-online.target
[Service]
Type=simple
User=myuser
ExecStart=/usr/local/bin/my-long-script.sh
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOFsudo systemctl daemon-reload
sudo systemctl enable --now myjob.service
一般的なデバッグ
- 障害状態のサービス: から
sudo journalctl -u rc-local.service -bログを表示するために使用します。. - 権限: ファイルが実行可能であることを確認してください（
chmod +x) であり、先頭にシバンが存在します。. - 相対パス: バイナリには常に絶対パスを使用してください。.
- 環境変数: rc.local には制限された環境があります。PATH などの変数を明示的に定義するか、完全なパスを記述します。.
- SELinux: AVC エラーを確認し、コンテキストを設定します。.
- 依存関係: スクリプトがネットワークまたはファイルシステムに依存する場合、単位は 後= そして 欲しいもの= それは適切であるはずです。.
代替案とベストプラクティス
- 専用 systemd ユニット: サービスには最適なオプションです。.
- crontab @再起動: 単純なユーザータスクに適しています:
@reboot /usr/local/bin/myscript.sh - クラウド初期化: クラウド環境での初期構成に適しています。.
- Ansible のような構成管理ツール: 繰り返し可能かつ管理可能な変更を行うために使用されます。.
セキュリティと運用のヒント
機密コマンドの実行から rc.local 避けてください。特定の所有権でスクリプトを実行するか、 ユーザー= systemd で使用されます。.
スクリプトの出力を常にログに記録し、権限を制限します。例:/usr/local/bin/myscript.sh >> /var/log/rc.local.log 2>&1
chmod 700 /usr/local/bin/myscript.sh実稼働環境では、重要なサーバーに変更を適用する前にステージング環境でテストします。.
この研修と当社のサービスとの関係
当社は、VPS、クラウド サーバー、グラフィック サーバー (GPU)、専用サーバー、ネットワークなど、世界 85 か所以上の拠点でサービスを提供しており、次のようなことが可能になります。
- トレーディングまたはゲーム用 VPS で起動スクリプトをすばやく実行します。.
- GPU サーバーでは、再起動後に処理が適切に開始されるように、systemd ユニットを使用して負荷の高いサービスを起動します。.
- ネットワーク サーバーと DDoS 対策サーバー上で、ネットワーク スクリプトと iptables を実行するためのカスタム systemd ユニットを作成します。.
- サポート チームは、SELinux、マウント パス、依存関係について対応します。.
結論と最終的な提案
systemdにもかかわらず、 rc.local これは起動時にカスタム コマンドを実行する簡単な方法ですが、安定性と監視のためには systemd ユニットを使用する方が適切です。.
権限、SELinux、サービスの依存関係に常に注意し、デバッグにはログを使用してください。.
特定のニーズ（自動取引ロボットの実行、GPU 環境の準備、ゲーム サーバーのネットワーク構成など）がある場合は、当社の技術チームがさまざまな場所でサポートいたします。.
