cronで動かしているスクリプトのエラーを見逃したり、いつ何が実行されたか追跡できなかったりするケースは少なくありません。
この記事では、
logger コマンドの使い方を体系的に解説します。システムログへの書き込み方法から、syslogファシリティ・プライオリティの指定、シェルスクリプトへの組み込みパターン、リモートホストへのログ転送、journalctlでの確認方法まで、実務で即使える内容を網羅します。この記事のポイント
・logger コマンドでシェルから /var/log/messages(syslog)に直接書き込める
・-t でタグを付けると grep / journalctl でスクリプト名で絞り込み検索できる
・-p でファシリティとプライオリティを指定してログの重要度を明示できる
・シェルスクリプトにログ関数として組み込むと cronジョブの管理が格段に楽になる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
loggerコマンドとは何か
logger はシェルの中から直接 syslog(rsyslog/systemd-journald)にメッセージを書き込むコマンドです。通常はシステムデーモンやカーネルが自動でログを出力しますが、logger を使うとシェルスクリプトやユーザーの操作からも同じ仕組みに乗ってログを残せます。「cronスクリプトのログを残したいけど、echoでファイルに書き出すしか方法を知らない」という場面はよくあります。しかし、次のようなコードには問題があります。
# よくある「echo でファイルに書き出す」パターン echo "$(date) バックアップ完了" >> /var/log/myapp.log
logger を使えば OS のログ管理の仕組みにそのまま乗れます。実務で
logger が役立つ場面は主に以下の3つです。・cronジョブの実行記録:スクリプトの開始・終了・エラーを /var/log/messages に残す
・監査目的のログ:重要な設定変更や操作を syslog に記録する
・リモートログサーバーへの集約:複数サーバーのスクリプトログを一箇所に転送する
logger は util-linux パッケージに含まれており、主要ディストリビューションで標準インストール済みです。動作確認した環境は以下のとおりです。・RHEL 9.4 / AlmaLinux 9.4 / Rocky Linux 9
・Ubuntu 24.04 LTS
・Amazon Linux 2023
# バージョン確認(インストール確認) $ logger --version logger from util-linux 2.37.4
loggerコマンドの基本的な使い方
1. シンプルなメッセージ書き込み
logger の最も基本的な使い方は、メッセージをそのまま引数で渡すだけです。# 書式 logger "メッセージ" # 実際のコマンド例 $ logger "バックアップスクリプトを開始しました" # RHEL系: /var/log/messages への記録確認 $ tail -3 /var/log/messages May 23 10:15:23 sv01 tomohiro: バックアップスクリプトを開始しました
Ubuntu / Debian 系では
/var/log/messages が存在しない場合があり、代わりに /var/log/syslog にログが書き込まれます。どちらの環境か分からない場合は journalctl で確認するのが確実です。# Ubuntu / Debian の場合 $ grep "tomohiro" /var/log/syslog May 23 10:15:23 ubuntu-server tomohiro: バックアップスクリプトを開始しました # どの環境でも使えるjournalctl確認 $ journalctl -t tomohiro --since "1 minute ago" May 23 10:15:23 sv01 tomohiro[12345]: バックアップスクリプトを開始しました
2. -t オプションでタグを指定する
-t タグ名 を付けると、ログの「ユーザー名」部分にタグが入ります。スクリプト名をタグにしておくと、grep / journalctl で絞り込みやすくなるため実務では必ず指定します。# タグを付けてログを書き込む $ logger -t backup_script "バックアップ処理を開始" $ logger -t backup_script "バックアップ処理が正常に完了しました" # 確認 $ tail -5 /var/log/messages May 23 10:30:01 sv01 backup_script: バックアップ処理を開始 May 23 10:30:45 sv01 backup_script: バックアップ処理が正常に完了しました # タグで絞り込む $ grep "backup_script" /var/log/messages May 23 10:30:01 sv01 backup_script: バックアップ処理を開始 May 23 10:30:45 sv01 backup_script: バックアップ処理が正常に完了しました
grep タグ名 /var/log/messages でそのスクリプトの実行ログだけを一瞬で抽出できます。3. -p オプションでファシリティとプライオリティを指定する
-p ファシリティ.プライオリティ でログの種別と重要度を指定できます。デフォルトは user.notice です。ファシリティ(facility)はログの発生源を示す分類です。スクリプトから記録する場合は通常
user または local0~local7(ユーザー用途に予約されたファシリティ)を使います。| ファシリティ | 意味 |
|---|---|
| user | 一般的なユーザーレベルのメッセージ(デフォルト) |
| local0 ~ local7 | カスタムアプリケーション用に予約(用途はサイトで自由に定義) |
| cron | cronデーモン関連のメッセージ |
| auth / authpriv | 認証・セキュリティ関連 |
| daemon | バックグラウンドデーモン関連 |
| syslog | syslogd 自体が発生させるメッセージ |
プライオリティ(priority)はログの重大度です。よく使うプライオリティは以下のとおりです。
| プライオリティ | 意味 | 使う場面 |
|---|---|---|
| emerg | 緊急(システム停止レベル) | 致命的障害 |
| alert | 即時対応が必要 | 深刻なエラー |
| crit | 重大なエラー | ハードウェア障害等 |
| err | エラー | スクリプトのエラー終了 |
| warn | 警告(warning も同義) | ディスク残量警告等 |
| notice | 通常だが注目すべき | 設定変更、サービス再起動 |
| info | 情報 | 正常処理の記録 |
| debug | デバッグ情報 | 開発・テスト時の詳細ログ |
# エラーレベルで書き込む $ logger -t backup_script -p local0.err "バックアップ先に接続できませんでした" # 情報レベルで書き込む $ logger -t backup_script -p local0.info "バックアップ処理を開始します" # 警告レベルで書き込む(warnとwarningはどちらも使用可) $ logger -t backup_script -p local0.warn "ディスク使用率が80%を超えました" # プライオリティのみ指定する場合(ファシリティはデフォルトのuserになる) $ logger -p err -t myapp "エラーが発生しました"
4. -i オプションでPIDを記録する
-i を付けると、ログにプロセスID(PID)が含まれます。同じスクリプトが並列で動いている場合に、どのプロセスが出力したログか区別できて便利です。# -i でPIDをログに含める $ logger -i -t batch_job "処理開始" # 確認(ブラケット内の数字がPID) $ grep "batch_job" /var/log/messages | tail -3 May 23 11:00:01 sv01 batch_job[28340]: 処理開始 May 23 11:00:01 sv01 batch_job[28341]: 処理開始 ← 別プロセスが同時実行
5. 標準入力からメッセージを渡す
コマンドの出力をlogger にパイプで渡すこともできます。スクリプトの実行結果をそのままログに記録する場合に便利です。# コマンド出力をloggerに渡す $ df -h / | logger -t disk_check # 確認 $ grep "disk_check" /var/log/messages | tail -5 May 23 10:45:10 sv01 disk_check: Filesystem Size Used Avail Use% Mounted on May 23 10:45:10 sv01 disk_check: /dev/sda1 50G 38G 9.5G 81% / # -f オプションでファイルの内容を1行ずつ送信 $ cat /tmp/result.txt | logger -t batch_output
応用・実務Tips
1. cronジョブにloggerを組み込む(最頻出パターン)
logger の最大の実務価値は、cronジョブのスクリプトへの組み込みです。スクリプトの開始・終了・エラーを全て syslog に記録することで、後から実行履歴をいつでも追跡できます。現場では、ログ記録をまとめた関数を定義するパターンが使いやすく定着しています。
#!/bin/bash # backup.sh — ログ関数を使ったスクリプト例 SCRIPT_NAME="backup_nightly" log_info() { logger -t "${SCRIPT_NAME}" -p user.info "$*" } log_warn() { logger -t "${SCRIPT_NAME}" -p user.warn "$*" } log_err() { # -s で標準エラーにも同時出力(cronのメール通知に拾わせる) logger -t "${SCRIPT_NAME}" -p user.err -s "$*" } # ---- ここからメイン処理 ---- BACKUP_SRC="/var/www/html" BACKUP_DEST="/mnt/nas/backup" log_info "バックアップ開始: ${BACKUP_SRC} -> ${BACKUP_DEST}" if [ ! -d "${BACKUP_DEST}" ]; then log_err "バックアップ先ディレクトリが存在しません: ${BACKUP_DEST}" exit 1 fi if rsync -a "${BACKUP_SRC}" "${BACKUP_DEST}"; then log_info "バックアップ正常完了" else log_err "バックアップ失敗: rsync が終了コード $? を返しました" exit 1 fi
/var/log/messages に実行記録が自動的に残ります。エラー発生時は user.err で記録されるため、rsyslog の設定でアラートメールを飛ばすことも可能です。2. 変数を展開してログに情報を含める
実務では、処理対象のファイル名・エラーコード・処理件数をログに含めることが多いです。DBダンプスクリプトを例に紹介します。#!/bin/bash SCRIPT_NAME="db_dump" TARGET_DB="production" DUMP_FILE="/backup/db_$(date +%Y%m%d).sql.gz" logger -t "${SCRIPT_NAME}" -p user.info \ "DBダンプ開始 DB=${TARGET_DB} 出力先=${DUMP_FILE}" mysqldump "${TARGET_DB}" | gzip > "${DUMP_FILE}" EXIT_CODE=$? if [ "${EXIT_CODE}" -eq 0 ]; then FILE_SIZE=$(du -sh "${DUMP_FILE}" | cut -f1) logger -t "${SCRIPT_NAME}" -p user.info \ "DBダンプ完了 ファイルサイズ=${FILE_SIZE}" else logger -t "${SCRIPT_NAME}" -p user.err \ "DBダンプ失敗 EXIT_CODE=${EXIT_CODE}" exit 1 fi
3. ファシリティ local0~local7 でアプリケーションを分類する
local0 から local7 はユーザー(アプリケーション)用のファシリティです。rsyslog でファシリティ別にログファイルを分けて管理できます。# /etc/rsyslog.d/99-local.conf に追記(rsyslogの設定例) # local0.* -> バックアップスクリプトのログ local0.* /var/log/backup.log # local1.* -> デプロイスクリプトのログ local1.* /var/log/deploy.log # rsyslog を再起動して設定を反映 $ sudo systemctl restart rsyslog # 以降、logger -p local0.info で書いたログは /var/log/backup.log に記録される $ logger -t backup_script -p local0.info "テスト書き込み" $ tail -1 /var/log/backup.log May 23 11:00:05 sv01 backup_script: テスト書き込み
4. -s オプションで標準エラーにも出力する
-s オプションを付けると、syslogへの書き込みと同時に標準エラー出力にも表示されます。テスト・デバッグ時に実際に何が記録されるかを確認するのに便利です。-s を使うと cron の MAILTO 設定にエラーを拾わせることもできます。# -s で端末にも表示しながら syslog に記録 $ logger -s -t test_script "これはテストメッセージです" test_script: これはテストメッセージです ← 端末にも出力 # syslogにも書き込まれている $ tail -1 /var/log/messages May 23 11:15:22 sv01 test_script: これはテストメッセージです
5. journalctlでログを絞り込む
systemd環境ではjournalctl を使えば、/var/log/messages を grep するよりも柔軟な絞り込みができます。# タグで絞り込む(logger -t で指定したタグ名に対応) $ journalctl -t backup_script # プライオリティ指定(err以上を表示) $ journalctl -p err -t backup_script # 時間範囲で絞り込む $ journalctl -t backup_script --since "2026-05-23 00:00:00" --until "2026-05-23 06:00:00" # 昨日の記録を確認 $ journalctl -t backup_script --since "yesterday" --until "today" # 最新10件だけ確認 $ journalctl -t backup_script -n 10 # リアルタイムでフォロー(tail -f 相当) $ journalctl -t backup_script -f
journalctl -t タグ名 は、logger で指定した -t タグに対応します。rsyslog がインストールされていない環境でも journalctl なら確認できるため、ログ確認の第一手として使うことを推奨します。リモートホストへのログ転送
1. -n オプションでリモートsyslogサーバーに直接送信する
logger は rsyslog の設定を変えなくても、-n ホスト名 -P ポート番号 でリモートの syslog サーバーに直接ログを送信できます。# リモートsyslogサーバー(192.168.1.100)のUDP 514番ポートへ送信 $ logger -n 192.168.1.100 -P 514 -t web01_backup "バックアップ完了" # TCP での送信(--tcp オプションを追加) $ logger --tcp -n 192.168.1.100 -P 514 -t web01_backup "バックアップ完了"
2. -f オプションでファイルの内容を送信する
-f ファイル名 でファイルの内容を1行ずつ syslog に送信できます。既存のログファイルや処理結果ファイルをそのまま syslog に取り込む際に役立ちます。# スクリプトの実行結果ファイルをsyslogに転送 $ logger -t result_check -f /tmp/job_result.txt # job_result.txtの中身 $ cat /tmp/job_result.txt 処理件数: 1523件 エラー件数: 0件 処理時間: 3分42秒 # syslogへの記録確認 $ grep "result_check" /var/log/messages May 23 11:30:10 sv01 result_check: 処理件数: 1523件 May 23 11:30:10 sv01 result_check: エラー件数: 0件 May 23 11:30:10 sv01 result_check: 処理時間: 3分42秒
トラブルシュート・よくあるミス
「logger: write error: Connection refused」が出る場合
rsyslog サービスが停止していたり、syslog ソケットが存在しない場合にこのエラーが発生します。# rsyslogの状態確認 $ sudo systemctl status rsyslog * rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled) Active: inactive (dead) ← 停止中 # rsyslogを起動する $ sudo systemctl start rsyslog $ sudo systemctl enable rsyslog # 再度loggerを試す $ logger -t test "rsyslog再起動後のテスト" $ tail -1 /var/log/messages May 23 11:40:05 sv01 test: rsyslog再起動後のテスト
「/var/log/messages にログが記録されない」場合
RHEL 9系や最新の Ubuntu 環境では、rsyslog がデフォルトでインストールされていない場合があります。journalctl ならインストールなしでも logger の出力を確認できます。# rsyslogのインストール確認 $ rpm -q rsyslog # RHEL系 $ dpkg -l rsyslog # Ubuntu系 # rsyslogが入っていない場合はインストール $ sudo dnf install rsyslog # RHEL9/AlmaLinux9/Rocky Linux9 $ sudo apt install rsyslog # Ubuntu # rsyslogの起動・自動起動設定 $ sudo systemctl enable --now rsyslog # journalctlならrsyslogがなくても動作確認できる $ journalctl -t myapp
journaldを使う環境でloggerが記録されない場合
systemd を採用している環境では、rsyslog が無効でもlogger は journald に記録されます。journalctl で確認してください。# journaldで確認 $ journalctl -t backup_script --since "1 hour ago" May 23 11:00:05 sv01 backup_script[12345]: バックアップ開始 # /var/log/messages に記録されない場合でも journalctl で取得できる # タグ(-t)で絞り込み可能なので logger の -t 指定は journald でも有効
ログが /var/log/messages に記録されない(Ubuntu / Debian 系)
Ubuntu では/var/log/messages が存在せず /var/log/syslog に書き込まれます。確認先を間違えないよう注意してください。# Ubuntu / Debian系の確認コマンド $ grep "backup_script" /var/log/syslog # どちらの環境か分からない場合はjournalctlで確認するのが確実 $ journalctl -t backup_script --no-pager | tail -10
マルチバイト文字(日本語)を含むメッセージが文字化けする
ロケールが適切に設定されていない cron 環境では、日本語メッセージが文字化けすることがあります。スクリプトの先頭で環境変数を明示的に設定することで回避できます。#!/bin/bash # cron から呼ばれる場合は LANG を明示する export LANG=ja_JP.UTF-8 export LC_ALL=ja_JP.UTF-8 logger -t batch_job "処理件数: 1523件"
本記事のまとめ
| やりたいこと | コマンド |
|---|---|
| シンプルにsyslogに書き込む | logger "メッセージ" |
| タグを付けて絞り込み可能にする | logger -t タグ名 "メッセージ" |
| エラーレベルで書き込む | logger -t タグ -p local0.err "メッセージ" |
| 端末にも同時表示する | logger -s -t タグ "メッセージ" |
| PIDをログに含める | logger -i -t タグ "メッセージ" |
| ファイルの内容をsyslogに送る | logger -t タグ -f ファイル名 |
| リモートsyslogサーバーに送信 | logger -n ホスト名 -P 514 "メッセージ" |
| journaldで確認する | journalctl -t タグ名 |
| タグでログを絞り込む | grep "タグ名" /var/log/messages |
logger はシンプルなコマンドですが、シェルスクリプトに組み込むことでサーバー運用の品質が大きく変わります。cronジョブが「動いたのかどうか分からない」状態から抜け出すために、まずはスクリプトの開始・終了の記録から始めてみてください。syslogのログ管理全体を理解するうえでは、systemd-analyze で起動時間計測の知識も合わせて持っておくと、システム起動からサービス稼働まで一連のログを体系的に把握できます。
また、ログに記録したい「どのタイミングでサービスが起動・停止したか」という情報は、ntpd 時刻同期設定で時刻がずれていないことを前提とします。ログの時刻精度はトラブル対応の命綱なので、合わせて確認しておくと万全です。
よくある質問(FAQ)
Q. logger コマンドは root 権限がなくても使えますか?
使えます。logger は一般ユーザーの権限でも実行でき、syslog に書き込めます。書き込まれたログには実行ユーザー名が自動付加されます。Q. cronスクリプトで logger を使う際に注意することは?
cron の実行環境は PATH が最小限に設定されているため、logger のフルパス(/usr/bin/logger)を指定するか、スクリプト先頭で PATH を明示的に設定することを推奨します。また、LANG の設定も合わせて行うと日本語の文字化けを防げます。#!/bin/bash # cronから呼ばれるスクリプトの先頭に追記 export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin export LANG=ja_JP.UTF-8 /usr/bin/logger -t my_job "cronスクリプト開始"
Q. logger で書いたログを自動削除(ローテーション)するにはどうすればいいですか?
logger の書き込み先である /var/log/messages は通常 logrotate で自動ローテーションされます。独自のファシリティ(local0 など)を使って別ファイルに書き出した場合は、/etc/logrotate.d/ にそのファイルのローテーション設定を追加してください。Q. ログの重要度(プライオリティ)をまとめて高いほうから並べると?
emerg(最高)> alert > crit > err > warn > notice > info > debug(最低)の順です。rsyslog では指定したプライオリティ以上のログのみを特定ファイルに書き出す設定も可能です。loggerでログ管理が改善されたなら、Linuxサーバー運用の全体像を体系的に学びませんか?
シェルスクリプトとloggerを組み合わせたログ管理は、現場で信頼されるサーバー管理者の必須スキルです。しかし個別コマンドの知識だけでは、本番環境での障害に冷静に対応できません。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 次のページへ:lsofコマンドで開いているファイルとポートを確認する方法|プロセス特定と障害切り分けの実践例も
- 前のページへ:nsenterコマンドでLinuxの名前空間に入る方法|コンテナデバッグと実務活用も
- この記事の属するカテゴリ:Linuxtipsへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます