Ubuntu 26.04 smartd の基本設定 – S.M.A.R.T. で物理ディスクを監視する

Ubuntu 26.04 の物理ホストで、smartmontools に含まれる smartd を使ってディスクの S.M.A.R.T. 状態を継続監視します。smartctl を必要な時だけ実行する方法とは異なり、smartd は daemon としてデバイスを定期確認し、異常をログへ記録します。

この記事では、物理ホストだけを適用対象にし、/etc/smartd.conf を検証してから配布し、警告を journald へ残す構成を扱います。ローカルメール通知や self-test の自動スケジュールは追加せず、まずは監視 daemon の土台を作ります。

smartctl と smartd の役割を分ける

機能	用途
`smartctl`	指定したデバイスの状態、属性、エラーログ、self-test 結果をその場で確認する
`smartd`	設定ファイルに基づいてデバイスを定期監視し、状態変化や異常をログへ記録する

障害調査では smartctl が必要ですが、毎回人がコマンドを実行しなければ異常に気付けない構成では、劣化の兆候を見落とします。smartd を常駐させ、異常の入口を journald に作ったうえで、詳細調査に smartctl を使います。

適用対象は SMART 情報を取得できる物理ホスト

Ubuntu 26.04 の smartmontools.service には、次の条件が定義されています。

ConditionVirtualization=no

通常の仮想マシンでは仮想ディスクから物理ドライブの S.M.A.R.T. 情報を直接取得できないため、サービスは起動条件を満たしません。仮想マシンへ設定ファイルを配布しても監視対象がなく、不要な構成管理になります。

物理 SATA / SAS / NVMe デバイスを直接持つホストを対象にする
通常の KVM、VMware、クラウド VM は対象外にする
PCI passthrough や USB passthrough で物理デバイスを直接公開した VM は個別に判断する
RAID controller や USB bridge を経由する場合は、対応する device type を確認する

パススルー構成で監視する場合は、systemd の起動条件だけを解除して終わりではありません。guest OS から smartctl で実際に S.M.A.R.T. 情報を読めることを先に確認します。

smartmontools をインストールする

sudo apt update
sudo apt install smartmontools
smartd --version
smartctl --version

パッケージには smartd、smartctl、systemd unit、設定ファイルの man page が含まれます。サービス名は smartmontools.service で、smartd.service は alias です。運用コマンドでは canonical name の smartmontools.service を使用します。

監視できるデバイスを確認する

設定を有効にする前に、OS が認識しているブロックデバイスと smartmontools が検出できるデバイスを確認します。

lsblk -d -o NAME,TYPE,ROTA,TRAN,MODEL,SERIAL
sudo smartctl --scan-open

lsblk に表示されても、RAID controller、USB-SATA bridge、仮想ディスクなどを経由すると、S.M.A.R.T. 情報を直接取得できない場合があります。検出結果に表示された device type と実際の接続方式を照合します。

個別デバイスの状態は、実際のデバイスパスへ置き換えて確認します。

sudo smartctl -H /dev/sda
sudo smartctl -a /dev/sda
sudo smartctl -a /dev/nvme0

すべてのホストに /dev/sda や /dev/nvme0 が存在するわけではありません。デバイス名を固定せず、smartctl --scan-open と lsblk の結果を基準にします。

smartd.conf の最小構成

今回の基本設定は次の 1 行です。

sudo tee /etc/smartd.conf > /dev/null <<'EOF'
DEVICESCAN -d removable -n standby
EOF

DEVICESCAN

DEVICESCAN は smartd がデバイスを走査し、検出した対象へ後続の directive を適用する指定です。DEVICESCAN より後の設定行は無視されるため、個別デバイスの設定を併用する場合は、その行を前に置きます。

-d removable

-d removable は「リムーバブルデバイスだけを監視する」というフィルターではありません。起動時にデバイスが存在しない場合でも smartd を終了させず、起動後にデバイスが取り外された場合の警告メールや反復ログを抑えるための指定です。

同じインターフェイスへ別のデバイスを差し替える運用は smartd の再起動が必要です。取り外し可能な媒体を許容することと、デバイス交換を自動追従することは同じではありません。

-n standby

-n standby は ATA ディスクが SLEEP または STANDBY の時に定期チェックをスキップし、smartd のポーリングによる不要なスピンアップを避けます。IDLE 状態ではチェックを行います。

この directive は ATA 向けです。また、smartd 起動時のデバイス登録処理までスピンアップさせないことを保証するものではありません。NVMe や常時回転させるディスクを含む混在環境では、デバイスごとの明示設定を検討します。

設定ファイルを配布前に検証する

設定ファイルを置いた後に構文エラーでサービスが起動できなくなることを防ぐため、smartd 自身で検証します。

sudo smartd -q showtests -c /etc/smartd.conf

-q showtests は設定を読み取り、設定されている self-test のスケジュールを表示して終了します。今回の最小構成には -s を含めていないため、定期 self-test が表示されなくても異常ではありません。重要なのは、設定解析がエラーなく完了することです。

現在の有効行も確認します。

sudo grep -Ev '^[[:space:]]*(#|$)' /etc/smartd.conf

smartmontools.service を有効化する

sudo systemctl enable --now smartmontools.service
sudo systemctl status smartmontools.service --no-pager -l

物理ホストでは active (running) になり、検出したデバイスがログへ記録されます。仮想マシンで起動条件を満たさない場合は、無理に unit の条件を上書きせず、そのホストを適用対象から外します。

設定変更後はサービスを再起動し、直近ログを確認します。

sudo systemctl restart smartmontools.service
sudo journalctl -u smartmontools.service --since today --no-pager

警告は journald へ記録する

今回の基本設定では -m によるローカルメール通知を設定しません。smartd の警告は systemd-journald に記録し、ホストログの集中管理や監視ルールから検出します。

smartd はディスクの状態変化と異常を journald へ記録する
ログ転送基盤は smartmontools unit と重要度を条件に収集する
通知先や抑制時間はログ基盤側の運用ルールで管理する
属性値や温度の時系列監視は exporter と Prometheus へ分ける

ログとメトリクスは役割が異なります。smartd は異常イベントの入口として使い、温度、Reallocated Sector Count、Media Errors などを継続的に可視化したい場合は、smartctl exporter などのメトリクス収集を別に構成します。

Ansible で設定を管理する

Ansible では、パッケージ、設定ファイル、サービスの 3 つを同じ責務として管理します。テンプレート配置時に smartd 自身の検証コマンドを実行し、検証に失敗したファイルを反映しないようにします。

- name: Install smartmontools
  become: true
  ansible.builtin.apt:
    name: smartmontools
    state: present
- name: Deploy smartd.conf
  become: true
  ansible.builtin.template:
    src: smartd.conf.j2
    dest: /etc/smartd.conf
    owner: root
    group: root
    mode: '0644'
    validate: /usr/sbin/smartd -q showtests -c %s
  notify: Restart smartmontools
- name: Enable smartmontools.service
  become: true
  ansible.builtin.systemd:
    name: smartmontools.service
    state: started
    enabled: true

handler は設定ファイルが変わった時だけサービスを再起動します。check mode では再起動しないようにし、設定差分の確認と実反映を分けます。

- name: Restart smartmontools
  become: true
  ansible.builtin.systemd:
    name: smartmontools.service
    state: restarted
  when: not ansible_check_mode

ロールの適用対象は inventory の専用グループなどで物理ホストへ限定します。仮想マシンを含む共通 OS ロールへ無条件に入れないことが重要です。

現在の設定で行うことと行わないこと

項目	現在の基本設定
デバイス検出	`DEVICESCAN` で自動検出
不在デバイス	`-d removable` で daemon の終了と反復警告を抑制
低電力状態	`-n standby` で ATA ディスクの定期スピンアップを回避
異常記録	journald へ記録
ローカルメール	使用しない
定期 self-test	スケジュールしない
属性の時系列収集	別の exporter で実装

smartd を起動しただけで、short test や long test が自動的に実行されるわけではありません。定期 self-test が必要な場合は、対象デバイス、実行時間、I/O 影響、スピンダウン方針を決めてから -s を追加します。

運用確認

適用後は、設定、サービス、ログ、個別デバイスを順に確認します。

sudo grep -Ev '^[[:space:]]*(#|$)' /etc/smartd.conf
sudo smartd -q showtests -c /etc/smartd.conf
sudo systemctl status smartmontools.service --no-pager -l
sudo journalctl -u smartmontools.service --since today --no-pager
sudo smartctl --scan-open

設定ファイルの有効行が想定どおりであること
設定解析がエラーなく完了すること
物理ホストでサービスが起動していること
監視対象デバイスが journald に記録されていること
対象外ホストへ設定を配布していないこと
ディスクを不必要にスピンアップさせていないこと

Ansible は 2 回実行し、2 回目が changed=0 になることも確認します。設定ファイルが同じなのに毎回サービスが再起動する場合は、template の生成内容や handler の通知条件を見直します。

構成を変更すべきケース

1 行の DEVICESCAN は導入の入口として扱いやすい一方、すべてのストレージ構成に十分ではありません。次の場合は個別デバイスの設定へ切り替えます。

RAID controller 配下で megaraid,N などの device type が必要な場合
USB-SATA bridge で sat などの指定が必要な場合
SATA HDD、SSD、NVMe で監視方針を分ける場合
ディスクごとに short test / long test の時刻を分ける場合
特定デバイスだけ温度や属性の閾値を変更する場合
取り外し可能なデバイスと固定ディスクを同じ扱いにしたくない場合

自動検出を使うか個別パスを列挙するかは、台数だけで決めません。controller 越しの見え方、デバイス交換、低電力運用、self-test の時間帯、障害通知の責任分界から選びます。

参考情報

まとめ

Ubuntu 26.04 で smartd を運用する時は、smartmontools を全ホストへ入れることよりも、SMART 情報を直接取得できる物理ホストへ適用対象を限定することが重要です。通常の仮想マシンは ConditionVirtualization=no の対象となり、仮想ディスクから物理ドライブの状態も取得できません。

DEVICESCAN -d removable -n standby は、デバイスの不在や取り外しを許容し、ATA ディスクの定期ポーリングによるスピンアップを避けるための最小設定です。ただし、定期 self-test、メール通知、属性の時系列監視までは構成しません。監視 daemon、イベントログ、メトリクス、self-test の役割を分け、必要な機能だけを追加します。

Ubuntu 26.04 smartd の基本設定 – S.M.A.R.T. で物理ディスクを監視する

Ubuntu 26.04 smartd の基本設定 – S.M.A.R.T. で物理ディスクを監視する

smartctl と smartd の役割を分ける

適用対象は SMART 情報を取得できる物理ホスト

smartmontools をインストールする

監視できるデバイスを確認する

smartd.conf の最小構成

DEVICESCAN

-d removable

-n standby

設定ファイルを配布前に検証する

smartmontools.service を有効化する

警告は journald へ記録する

Ansible で設定を管理する

現在の設定で行うことと行わないこと

運用確認

構成を変更すべきケース

参考情報

まとめ

関連記事

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル