ログを見ても数値が残っていない。こんな悔しい思いをしたことはないでしょうか。
sarコマンドを使えば、CPU・メモリ・ディスク・ネットワークの負荷統計を過去に遡って確認できます。
RHEL 9 / Rocky Linux 9 / AlmaLinux 9 / Ubuntu 24.04 LTS で動作確認済みです。
この記事では、sarコマンドの基本的な使い方から、実務で役立つ過去データの読み方、コアごとのCPU分析、スワップ・ロードアベレージの確認、高負荷インシデントの事後調査手順、CSV出力による分析活用、保存日数の調整方法、よくあるトラブルの対処法まで解説します。
この記事のポイント
・sar -u/-r/-b/-d/-S/-q で CPU・メモリ・ディスク・スワップ・ロードを時系列で確認できる
・sar -f /var/log/sa/saXX で過去の統計データをさかのぼって参照でき、-s/-e で時刻帯も絞れる
・RHEL 9 は sysstat-collect.timer の有効化、Ubuntu は ENABLED="true" への変更が前提条件
・sadf -d でCSV出力してExcelでトレンド分析する使い方も実務で便利
・-P ALL オプションでコアごとのCPU偏りも確認できる
・/etc/sysconfig/sysstat（RHEL系）の HISTORY を変更することでデータ保存日数を調整できる（デフォルト28日）
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
sarコマンドとは？sysstatが提供するパフォーマンス記録の仕組み
sarはSystem Activity Reporterの略で、sysstatパッケージに含まれるコマンドです。Linuxのカーネルが収集しているCPU・メモリ・ディスクI/O・ネットワークなどのパフォーマンス統計を、時系列で記録・参照できます。
topやvmstatは「今この瞬間」の値しか確認できませんが、sarは「昨日の15時ごろのCPU使用率」「先週のメモリ使用量の推移」を確認できます。「5分前のCPU使用率」「昨日14時のメモリ使用量」のように後から時系列で調べられるのがsarの最大の強みです。障害の事後調査（ポストモーテム）やキャパシティプランニングに欠かせないツールです。
sysstatパッケージには、データ収集を担うsadc（System Activity Data Collector）と、それを呼び出すラッパースクリプトsa1（定期収集）・sa2（日次サマリ生成）が含まれています。RHEL 9系ではsystemdのタイマーユニット（sysstat-collect.timer）が10分おきにsa1を呼び出し、収集したバイナリデータを
/var/log/sa/ に蓄積します。sarはその蓄積データを読み出して人が読める形式で出力するコマンドです。他の監視ツールとの違いをまとめると以下のようになります。
| ツール | 用途 | 過去ログ | 主な対象リソース |
|---|---|---|---|
top / htop |
リアルタイム監視 | なし | CPU・メモリ・プロセス |
vmstat |
リアルタイム・短期集計 | なし | CPU・メモリ・I/O |
iostat |
リアルタイム・短期集計 | なし | CPU・ディスクI/O |
sar |
時系列分析・傾向把握 | あり（28日分） | CPU・メモリ・ディスク・ネットワーク |
・過去の履歴確認：sar（sysstat）
この使い分けが実務での基本です。sysstatをインストールして収集タイマーを有効化すると、10分おきにシステム統計が収集され、/var/log/sa/ 以下にバイナリ形式で保存されます。デフォルトで28日分のデータが保持されます（HISTORY設定で変更可能）。
sysstatのインストールと有効化
1. sysstatパッケージをインストールする
RHEL系（Rocky Linux / AlmaLinux / RHEL）の場合:# dnf install sysstat -y
# apt install sysstat -y
2. sysstatサービスを有効化する
インストール直後はデータ収集が開始されていないため、収集を有効化する必要があります。RHEL 9 / Rocky Linux 9ではsysstatがsystemdのタイマーユニットで管理されているため、以下のコマンドで有効化します。# sysstat-collect.timer を有効化（10分ごとのデータ収集） # systemctl enable --now sysstat-collect.timer # sysstat-summary.timer も有効化（日次サマリ生成） # systemctl enable --now sysstat-summary.timer # 状態確認（Active: active (waiting) が正常） # systemctl status sysstat-collect.timer
Ubuntuではsysstatの有効化設定が別途必要です。/etc/default/sysstatを編集してください。
# /etc/default/sysstatを編集（ENABLED="false" → "true" に変更） # sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat # sysstatサービスを再起動 # systemctl restart sysstat
3. データ収集の確認
インストール後、データファイルの生成を確認します。RHEL 9系ではcronとsystemd timerの両方で管理される場合があります。どちらが有効かは以下で確認できます。# systemd timerの確認（RHEL 9 / AlmaLinux 9） # systemctl list-timers | grep sysstat # RHEL系のcronジョブ確認 # cat /etc/cron.d/sysstat # Run system activity accounting tool every 10 minutes */10 * * * * root /usr/lib64/sa/sa1 1 1 # Generate a daily summary of process accounting at 23:53 53 23 * * * root /usr/lib64/sa/sa2 -A
# ls /var/log/sa/ sa25 sa26 sar25 sar26
4. データ保存日数を変更する（オプション）
デフォルトは28日分のデータが保持されます。長期トレンド分析や遡り調査の範囲を広げたい場合は、設定ファイルの HISTORY 値を変更します。RHEL 9系の設定ファイルは/etc/sysconfig/sysstat、Ubuntuは /etc/sysstat/sysstat です。# RHEL 9系の場合（設定ファイルを確認） # cat /etc/sysconfig/sysstat HISTORY=28 COMPRESSAFTER=10 # 10日経過後に古いデータをgzip圧縮 # 90日分に変更する場合（ディスク容量に注意） # sed -i 's/HISTORY=28/HISTORY=90/' /etc/sysconfig/sysstat
sarの基本的な使い方
1. CPU使用率をリアルタイムで確認する
# sar -u 1 5 Linux 5.14.0-362.8.1.el9_3.x86_64 (web01.example.com) 2026-04-26 _x86_64_ (4 CPU) 12:00:01 CPU %user %nice %system %iowait %steal %idle 12:00:02 all 5.26 0.00 1.50 0.25 0.00 92.99 12:00:03 all 4.77 0.00 1.25 0.00 0.00 93.98 12:00:04 all 6.52 0.00 2.01 0.00 0.00 91.47 12:00:05 all 5.01 0.00 1.48 0.13 0.00 93.38 12:00:06 all 5.39 0.00 1.56 0.06 0.00 92.99 Average: all 5.39 0.00 1.56 0.09 0.00 92.96
各カラムの意味は以下のとおりです。
・%user：ユーザープロセスがCPUを使った割合
・%system：カーネルがCPUを使った割合（システムコール・割り込み処理）
・%iowait：ディスクI/O待ちによってCPUが空いた割合。高いとディスクがボトルネックの可能性があります
・%steal：仮想化環境（クラウドのVMなど）で、他のVMに奪われたCPU時間の割合。5%を超えると体感遅延が出始めます
・%idle：CPUが何もしていない割合
2. コアごとのCPU使用率を確認する（-P ALL）
複数コアのサーバーで特定コアだけに負荷が偏っている場合、-P ALLオプションを使うと各コアの状態を個別に確認できます。# sar -u -P ALL 1 3 12:00:01 CPU %user %nice %system %iowait %idle 12:00:02 all 8.42 0.00 2.15 0.53 88.90 12:00:02 0 15.84 0.00 4.00 0.00 80.16 12:00:02 1 1.02 0.00 0.51 0.00 98.47 12:00:02 2 2.04 0.00 1.02 1.53 95.41 12:00:02 3 14.79 0.00 3.06 0.00 82.15
3. 主要オプション一覧
・-u：CPU使用率の統計・-P コア番号 / ALL：指定コア（または全コア）ごとのCPU使用率
・-r：メモリ使用状況の統計
・-b：ディスクI/Oの統計（tps・読み書き速度の概要）
・-d：ブロックデバイスごとのI/O統計（-p と組み合わせてデバイス名を人が読める形で表示）
・-n DEV：ネットワークインターフェースの統計
・-n EDEV：ネットワークエラー（パケットロス・ドロップ）の統計
・-S：スワップ使用状況の統計
・-W：スワップイン/アウトの転送量統計
・-q：ロードアベレージとプロセス数の統計
・-A：すべての統計を一括表示
・-f ファイルパス：指定したデータファイルを参照
・-s HH:MM:SS：表示開始時刻を指定
・-e HH:MM:SS：表示終了時刻を指定
過去のデータを参照する方法
1. 当日の統計を確認する
引数なしで実行すると、当日の統計が表示されます。# sar -u # または明示的にファイルを指定する # sar -u -f /var/log/sa/sa26
2. 過去の日付のデータを参照する
saファイルを -f で指定することで、過去の日付のデータを確認できます。# 25日のCPU統計を確認する # sar -u -f /var/log/sa/sa25 Linux 5.14.0-362.8.1.el9_3.x86_64 (web01.example.com) 2026-04-25 _x86_64_ (4 CPU) 00:00:01 CPU %user %nice %system %iowait %steal %idle 00:10:01 all 2.13 0.00 0.85 0.05 0.00 96.97 00:20:01 all 2.45 0.00 0.91 0.03 0.00 96.61 ... 15:00:01 all 72.35 0.00 18.42 3.21 0.00 6.02 15:10:01 all 83.12 0.00 14.97 2.88 0.00 0.03 15:20:01 all 25.14 0.00 5.43 0.95 0.00 68.48 ...
gzip圧縮されたファイル（COMPRESSAFTER日数を超えた古いデータ）もsarはそのまま読み込めます。
# 保存されているsaファイルを一覧で確認 # ls -lh /var/log/sa/sa[0-9][0-9] # gzip圧縮されたファイルはそのまま読める # sar -u -f /var/log/sa/sa01.gz
3. 時間帯を絞り込んで確認する
-s（start）と -e（end）オプションで表示範囲を絞れます。報告された障害発生時刻の前後30分を確認するとき、このオプションで素早く絞り込めます。# 昨日の14:00から16:00のCPUデータだけ確認する # sar -u -f /var/log/sa/sa25 -s 14:00:00 -e 16:00:00 # 同じ時間帯のメモリ統計と組み合わせる # sar -r -f /var/log/sa/sa25 -s 14:00:00 -e 16:00:00 # ロードアベレージで高負荷の時刻を絞り込む # sar -q -f /var/log/sa/sa25 -s 14:00:00 -e 16:00:00
各統計の読み方と実務Tips
1. メモリ統計（-r）
# sar -r -f /var/log/sa/sa25 -s 15:00:00 -e 16:00:00 15:00:01 kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit 15:00:01 125440 4250112 3874560 96.89 102400 2048000 8192000 102.40
・%memused：メモリ使用率。90%を超えているとスワップへの圧力が高まっています
・kbavail：実際に利用可能なメモリ（ページキャッシュの解放分を含む）。メモリ不足の判断は kbmemfree ではなく kbavail を基準にしてください。kbavail が極端に少なければ、プロセスのメモリリーク調査が必要です
・kbcommit：カーネルが「使うと約束した」仮想メモリ量（プロセスが確保を宣言したが実際には未使用の分を含む）
・%commit：kbcommit が物理メモリ+スワップに対して何%か。100%を超え始めるとOOM Killerが発動するリスクが高まります
OOM Killerが発動した可能性があれば /var/log/messages で詳細を確認できます。
2. ブロックI/O概要（-b）
-b オプションはシステム全体のI/O転送量を手早く把握するのに使います。デバイス別の内訳は後述の -d で確認します。# sar -b -f /var/log/sa/sa25 -s 15:00:00 -e 16:00:00 15:00:01 tps rtps wtps bread/s bwrtn/s 15:00:01 15.3 12.1 3.2 1024.5 256.8 15:10:01 312.4 280.1 32.3 22528.0 2592.7 15:20:01 18.2 14.5 3.7 1168.0 296.0
・rtps：読み取りリクエスト/秒
・wtps：書き込みリクエスト/秒
・bread/s / bwrtn/s：ブロック単位の読み取り・書き込み量/秒
15:10台にtpsが急増しているのがわかります。この時刻のCPU %iowaitと照合すれば、I/Oがボトルネックになっていたかどうかを判断できます。
3. ディスクI/O統計（-d）
-p オプションを組み合わせると、デバイス名が人が読める形（sda、nvme0n1など）で表示されます。複数デバイスがある環境では、どのデバイスがボトルネックかを一目で特定できます。# sar -d -p -f /var/log/sa/sa25 -s 15:00:00 -e 16:00:00 15:00:01 DEV tps rkB/s wkB/s areq-sz aqu-sz await %util 15:00:01 sda 12.33 45.20 92.80 11.21 0.02 1.24 1.52 15:00:01 sdb 274.33 3162.40 854.20 14.65 3.84 14.02 98.43
・wkB/s：1秒あたりの書き込み量（KB）
・%util：デバイスの使用率。70%を超えたらI/Oボトルネックの目安です。sdbは98%と飽和状態
・await：I/Oリクエストの平均待ち時間（ms）。高いほど遅延が大きい
・aqu-sz：I/Oキューに積み上がっているリクエスト数。増加し続けている場合はデバイスが追いついていない状態です
sdbの %util が98%・aqu-sz が3.84というのは、このデバイスがほぼ飽和している状態です。大量書き込み処理が重なっている場合は `sar -b` の bwrtn/s と合わせて確認してください。
4. ネットワーク統計（-n DEV）
# sar -n DEV -f /var/log/sa/sa25 -s 15:00:00 -e 15:30:00 15:00:01 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 15:00:01 eth0 520.33 480.12 62.45 48.12 0.00 0.00 0.00
5. ネットワークエラー統計（-n EDEV）
パケットロスやNICエラーが発生していないかを確認するには -n EDEV を使います。# sar -n EDEV -f /var/log/sa/sa25 -s 15:00:00 -e 15:30:00 15:00:01 IFACE rxerr/s txerr/s coll/s rxdrop/s txdrop/s 15:00:01 eth0 0.00 0.00 0.00 12.5 0.00
6. スワップ使用量（-S）
# sar -S -f /var/log/sa/sa25 -s 15:00:00 -e 16:00:00 15:00:01 kbswpfree kbswpused %swpused kbswpcad %swpcad 15:00:01 4194304 0 0.00 0 0.00 15:10:01 2097152 2097152 50.00 524288 25.00 15:20:01 524288 3670016 87.50 917504 25.00
7. ロードアベレージ（-q）
# sar -q -f /var/log/sa/sa25 -s 15:00:00 -e 16:00:00 15:00:01 runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked 15:00:01 1 412 0.12 0.15 0.18 0 15:10:01 48 687 12.34 10.21 8.45 5
8. すべての統計を一括確認（-A）
障害調査の最初の一歩として、`-A` で全リソースのデータを一覧取得してからあとで絞り込む方法が効率的です。# 昨日の全統計をlessで確認する # sar -A -f /var/log/sa/sa25 | less # 特定時間帯に絞り込む # sar -A -f /var/log/sa/sa25 -s 14:00:00 -e 16:00:00
高負荷インシデントをsarで事後調査する実践手順
「昨夜22時ごろにアプリケーションの応答が遅くなった」という報告があったとします。sarを使った事後調査の流れを示します。1. まずロードアベレージで高負荷の時刻を特定する
# 前日のロードアベレージを確認（前日=25日なら sa25） # sar -q -f /var/log/sa/sa25 -s 21:00:00 -e 23:30:00 # 出力例 21:00:01 runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked 21:10:01 2 412 0.32 0.28 0.25 0 21:20:01 2 415 0.35 0.30 0.27 0 21:30:01 18 445 3.87 1.42 0.58 3 21:40:01 32 489 7.23 4.88 2.14 8 21:50:01 28 478 6.94 5.72 3.44 5 22:00:01 12 452 4.18 5.11 4.02 2 22:10:01 3 421 1.22 3.04 3.48 0 22:20:01 2 416 0.48 1.52 2.44 0
2. CPU・I/Oの原因を切り分ける
# 同じ時間帯のCPU統計で原因を絞る # sar -u -f /var/log/sa/sa25 -s 21:20:00 -e 22:10:00 # 出力例 21:20:01 CPU %user %nice %system %iowait %steal %idle 21:30:01 all 8.42 0.00 3.22 62.14 0.02 26.20 21:40:01 all 12.18 0.00 4.87 71.32 0.02 11.61 21:50:01 all 9.74 0.00 4.12 74.88 0.01 11.25 22:00:01 all 6.34 0.00 2.78 51.23 0.01 39.64
3. ディスクI/Oの量とデバイスを特定する
# 同じ時間帯のI/O統計 # sar -b -f /var/log/sa/sa25 -s 21:20:00 -e 22:10:00 # デバイス別に確認してどのストレージが原因か特定する # sar -d -p -f /var/log/sa/sa25 -s 21:20:00 -e 22:10:00
このように
sar -q で高負荷時刻を特定 → sar -u の %iowait/%user で CPU かI/Oかを切り分け → sar -d でデバイスを特定、という3ステップが事後調査の基本手順です。CSV出力とExcel分析（sadfコマンド）
sarのデータをCSVやJSONに変換して外部ツールで分析できます。sadfコマンドを使います。# CSV形式で出力（Excelで開ける） # sadf -d /var/log/sa/sa25 -- -u > /tmp/cpu_sa25.csv # JSON形式で出力 # sadf -j /var/log/sa/sa25 -- -u > /tmp/cpu_sa25.json # メモリ統計をCSVで出力 # sadf -d /var/log/sa/sa25 -- -r > /tmp/mem_sa25.csv
キャパシティプランニングでは、1週間分のCSVをExcelに取り込んでCPUやメモリのトレンドをグラフ化する使い方が便利です。
sysstatにはsa2スクリプトも含まれており、日次サマリを /var/log/sa/sar[日付] に自動生成します。手動で前日分のレポートを生成するには以下のコマンドを使います。
# 日次サマリを手動生成（前日分） # /usr/lib64/sa/sa2 -A # 生成されたレポートを確認 # cat /var/log/sa/sar25
トラブルシュート・エラー対処
「Cannot open /var/log/sa/saXX」が出た時の対処法
対象日付のファイルが存在しない場合に発生します。以下を確認してください。# sysstatタイマーの状態を確認（RHEL 9系） # systemctl status sysstat-collect.timer # sysstatサービスの状態を確認（Ubuntu系） # systemctl status sysstat # 手動でデータ収集を実行（テスト用） # /usr/lib64/sa/sa1 1 1 # ls -l /var/log/sa/
デフォルトでは28日分のデータが保持されます。それ以前のデータは取得できません。
「Requested activities not available」が出た時の対処法
古いsaファイルのバージョンと現在のsarコマンドのバージョンが合わない場合に発生します。# sysstatのバージョン確認 # sar --version sysstat version 12.5.4 # sadfコマンドでファイルのバージョン情報を確認 # sadf -H /var/log/sa/sa01
sarコマンドが見つからない時の対処法
sysstatがインストールされていないとsarコマンドが見つかりません。パッケージを確認してインストールします。# sarが含まれるパッケージを確認（RHEL系） # rpm -qf $(which sar) 2>/dev/null sysstat-12.5.4-5.el9.x86_64 # インストールされていない場合 # dnf install sysstat -y
Ubuntuでデータが収集されない時の対処法
# /etc/default/sysstatの確認 # grep ENABLED /etc/default/sysstat ENABLED="false" # この場合は "true" に変更してサービスを再起動する # sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat # systemctl restart sysstat
表示データがすべて0になる（RHEL系）
sysstatのタイマーは起動しているが sa1 の実行パスが合っていない場合があります。# sa1の場所を確認 # rpm -ql sysstat | grep sa1 /usr/lib64/sa/sa1
「No data available for this period」が出た時の対処法
指定した時刻範囲にデータが存在しない場合です。収集間隔（デフォルト10分）の隙間を指定してしまうと表示されません。ログファイルに記録されている時刻を先に確認してから -s/-e で絞り込みましょう。# まずログの記録時刻を確認してから時刻を絞る # sar -u -f /var/log/sa/sa25 | head -20
収集間隔を変更したい場合（RHEL 9系）
デフォルトは10分ごとですが、障害が頻発する環境では5分に変更することがあります。systemdのオーバーライドファイルで変更します。# オーバーライドファイルを作成して収集間隔を5分に変更する # mkdir -p /etc/systemd/system/sysstat-collect.timer.d/ # cat > /etc/systemd/system/sysstat-collect.timer.d/override.conf <<'EOF' [Timer] OnCalendar= OnCalendar=*:00/5 EOF # systemctl daemon-reload # systemctl restart sysstat-collect.timer
本記事のまとめ
| やりたいこと | コマンド |
|---|---|
| CPU使用率をリアルタイムで確認する | sar -u 1 10 |
| 当日のCPU統計をすべて表示する | sar -u |
| コアごとのCPU使用率を確認する | sar -u -P ALL |
| 25日のデータを確認する | sar -u -f /var/log/sa/sa25 |
| 15時から16時のデータに絞る | sar -u -f /var/log/sa/sa25 -s 15:00:00 -e 16:00:00 |
| メモリ使用状況を確認する | sar -r -f /var/log/sa/sa25 |
| ブロックI/O概要を確認する | sar -b -f /var/log/sa/sa25 |
| ディスクI/Oをデバイス名付きで確認する | sar -d -p -f /var/log/sa/sa25 |
| ネットワーク統計を確認する | sar -n DEV -f /var/log/sa/sa25 |
| ネットワークエラーを確認する | sar -n EDEV -f /var/log/sa/sa25 |
| スワップ使用量を確認する | sar -S -f /var/log/sa/sa25 |
| スワップイン/アウトを確認する | sar -W -f /var/log/sa/sa25 |
| ロードアベレージを確認する | sar -q -f /var/log/sa/sa25 |
| 全リソースを一覧確認する | sar -A -f /var/log/sa/sa25 |
| CSV出力で分析ツールへ渡す | sadf -d /var/log/sa/sa25 -- -u > cpu.csv |
| データ保存日数を変更する（RHEL系） | grep HISTORY /etc/sysconfig/sysstat |
事後調査の基本手順は「
sar -q のldavgで高負荷の時刻を特定 → sar -u の%iowait・%userでCPUかI/Oかを切り分け → sar -d -p でデバイスを特定」の3ステップです。この流れを一度体に染み込ませておくと、深夜の障害連絡を受けた時でも落ち着いて原因に近づけます。継続的なデータ収集がない環境では事後調査ができないため、まずsysstatのインストールとsysstat-collect.timerの有効化から始めることをおすすめします。起動後10分待てば最初のデータが蓄積されます。
システム管理のコマンドをもっと体系的に学びたい方は、systemd-analyze で起動時間計測やLinux ポート確認の全コマンドの記事も参考にしてください。
「サーバーが遅い」と言われた時に、データで説明できますか？
sarのようなパフォーマンス監視ツールは、障害の事後証明だけでなく予防保全にも使えます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
＜PR＞手元に置いて学びを深める1冊
詳解 システム・パフォーマンス 第2版（Brendan Gregg 著／オライリー・ジャパン）
まず無料メルマガでLinuxの基礎を固めるのが第一歩ですが、CPUやI/Oのボトルネックを腰を据えて分析するなら、sarから最新のBPFまで体系的に導いてくれる本書が手元にあると心強いです。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：getoptsコマンドでbashスクリプトの引数を処理する方法｜オプション解析と実践例も
- 前のページへ：nohupコマンドでSSH切断後もコマンドを実行し続ける方法｜バックグラウンド実行とログ保存の実践例も
- この記事の属するカテゴリ：Linuxtips・システム管理コマンド・システム管理コマンドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます