OS再起動後にWebサーバーやNTPクライアントが起動していなかった、というトラブルは実務でよく起こります。CentOS 7以降・Ubuntu 16.04以降をはじめとする現代のLinuxは systemd を採用しており、サービスの自動起動設定は systemctl コマンドで一元管理します。古い記事でよく見かける chkconfig コマンドはSysVinit時代の書式で、現在の主要ディストリビューションでは原則使用しません。ランレベルという概念も「ターゲット」に置き換わっており、操作そのものはシンプルになっています。
まず結論:自動起動を有効化する1コマンド
nginxを例に取ると、OS起動時の自動起動を有効化するコマンドは次の通りです。
sudo systemctl enable nginx
実行すると /etc/systemd/system/multi-user.target.wants/nginx.service などにシンボリックリンクが作成され、次回起動時から自動的にサービスが呼び出されます。前後の状態を確認するには is-enabled サブコマンドを使います。
# 有効化前の確認
systemctl is-enabled nginx
# → disabled
# 有効化
sudo systemctl enable nginx
# Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service ...
# 有効化後の確認
systemctl is-enabled nginx
# → enabled
重要: enable は「次回起動時以降の設定変更」であり、現在稼働中のサービスには影響しません。今すぐ起動したい場合は別途 sudo systemctl start nginx が必要です。両方を一度に済ませる方法は後述します。
現在の自動起動状態を確認する
設定変更の前に現状を把握しておくと、意図せず他のサービスを止めたり、すでに有効化されているものを二重設定するミスを防げます。
# 特定サービスの状態を確認
systemctl is-enabled sshd
# 全サービスの自動起動状態を一覧表示
systemctl list-unit-files --type=service
# enabled 状態のサービスだけに絞り込む
systemctl list-unit-files --type=service --state=enabled
is-enabled が返す主な状態と意味を整理します。
| 状態 | 意味 |
|---|---|
enabled | 自動起動する設定になっている |
disabled | 自動起動しない設定になっている |
masked | 完全に封印されており、手動起動も受け付けない |
static | 有効化・無効化の対象外(他サービスに依存する補助ユニット等) |
static 状態のユニットに対して enable を実行しようとしても “Unit file has no installation config” と表示されるだけで変化しません。これはバグではなく設計によるものです。
設定と即時起動・停止を一度に済ませる
ある運用現場では、enable 後に start を実行し忘れてサービスが停止したまま気づかず、夜間バッチが失敗したという事例があります。--now オプションを付けることで設定変更と起動(または停止)を一括で行えます。
# 自動起動を有効化し、さらに今すぐ起動する
sudo systemctl enable --now nginx
# 自動起動を無効化し、さらに今すぐ停止する
sudo systemctl disable --now nginx
サーバーの初期セットアップや設定変更作業では、この --now 付きの形式を常用することで「設定は入れたが起動し忘れた」というミスを根本から防げます。実行後は systemctl status nginx でプロセスが実際に動いているかを確認する習慣をつけてください。
複数のサービスをまとめて設定する
新規サーバーのセットアップ時など、複数サービスをまとめて有効化したい場合はスペース区切りで列挙します。
# 複数サービスをまとめて有効化
sudo systemctl enable nginx chronyd sshd
# 有効化と即時起動をまとめて実行
sudo systemctl enable --now nginx chronyd sshd
# まとめて状態確認
systemctl is-enabled nginx chronyd sshd
サービス名は nginx でも nginx.service でも動作します。ただし、タイマーユニット(.timer)やソケットユニット(.socket)を指定する場合は拡張子を明示してください。なお ntpd は旧来のNTPデーモンで、現代のRHEL系では chronyd、Debian/Ubuntu系では systemd-timesyncd や chrony が標準です。
masked 状態のサービスを有効化するには
systemctl enable を実行した際に “Failed to enable unit: Unit file … is masked.” というエラーが返ることがあります。masked 状態は管理者が意図的に設定した封印で、enable も start も受け付けません。解除するには先に unmask が必要です。
# masked 状態を確認
systemctl is-enabled firewalld
# → masked
# unmask してから有効化・起動
sudo systemctl unmask firewalld
sudo systemctl enable --now firewalld
# 状態を確認
systemctl is-enabled firewalld
# → enabled
unmask は慎重に: マスク設定はセキュリティポリシーやコンテナ環境の制約として意図的に施されている場合があります。特にクラウドのベースイメージでは、不要なサービスが意図的にマスクされているケースが多いため、組織のポリシーや構成管理ツール(AnsibleやChef等)の設定と照らし合わせてから外してください。
旧来のランレベル指定との対応関係
SysVinit時代(CentOS 6以前など)では chkconfig --level 35 ntpd on のようにランレベルを明示的に指定していました。systemd ではランレベルという概念が「ターゲット」に置き換わっています。主な対応は次の通りです。
| 旧ランレベル | systemd ターゲット | 主な用途 |
|---|---|---|
| 3 | multi-user.target | サーバー(CLIのみ) |
| 5 | graphical.target | デスクトップ環境 |
systemctl enable はサービスの unit ファイルに記述された WantedBy= の値を読み取り、自動的に適切なターゲットへのリンクを作成します。サーバー用途では大半のサービスが WantedBy=multi-user.target を持っているため、ターゲットを意識せずに systemctl enable だけで設定が完結します。
特定ターゲット向けに明示的に登録したい場合(上級者向け)は --target オプションで指定できますが、通常の運用では不要です。
# サービスがどのターゲットに紐づいているかを確認する
systemctl cat nginx | grep WantedBy
# → WantedBy=multi-user.target
自動起動の設定変更は enable / disable の二択がほぼすべてです。ランレベル番号を覚える必要はなく、操作はシンプルになっています。設定後は必ず systemctl is-enabled で意図した状態になっているかを確認してから作業を終えてください。
「コマンドは打てる。次は”現場で通用する型”を最短で身につけたい」——そんなあなたへ。
ネットの断片的なTipsをコピペするだけでは、体系的な運用スキルはなかなか積み上がりません。リナックスマスター.JPの無料メルマガ「リナマガ」では、現場で実際に使うLinuxサーバー運用の考え方を、順を追って実務目線でお届けしています。いま登録された方には、安全なサーバー構築の「型」をまとめた『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼント中です。
>> 図解60P『Linux入門マニュアル』を無料で受け取る
(メルマガ登録は10秒・いつでも解除OK)
※ 「独学の時間がもったいない」「プロから現場の技術を最短で学びたい」という本気の方には、2日で実務レベルが身につく初心者向けハンズオンセミナーもご用意しています。
