CentOS 5 の sysstat の採取周期を 1 分毎に変更

CentOS 5 のデフォルトの sysstat 採取周期は 10 分になっているが、これだとアラ過ぎると感じることがあるので、自分の管理しているサーバでは 1 分周期に変更している。

デフォルトの /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

これを、次のように変更する。

# run system activity accounting tool every 1 minutes
*/1 * * * * 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

もちろん、格納ファイル (/var/log/sa/saXX, XX は日付) のサイズは 10 倍になるのだが、デフォルトの 10 分間隔で、500 KB/日 程度のものなので、今の大容量時代では、10 倍になったところで取るに足りない。過去 7日分 (/etc/sysconfig/sysstat の HISTORY で指定) として、5MB x 7 = 35 MB ほど。

sar のデータをグラフ化する場合などに、10 分毎のサンプルのほうが都合がいいこともあるかもしれないが、そのような場合は、sar -i オプションを使えばいい。

# sar -f /var/log/sa/sa25 | head -35
Linux 2.6.18-194.26.1.el5 (my41)        12/25/2010

12:00:01 AM       CPU     %user     %nice   %system   %iowait    %steal     %idle
12:01:01 AM       all      0.05      0.00      0.12      0.01      0.00     99.82
12:02:01 AM       all      0.04      0.00      0.16      0.00      0.00     99.80
12:03:01 AM       all      0.17      0.00      0.32      0.01      0.00     99.51
12:04:01 AM       all      0.04      0.00      0.13      0.00      0.00     99.83
12:05:01 AM       all      0.06      0.00      0.17      0.00      0.00     99.77
12:06:01 AM       all      0.03      0.00      0.15      0.00      0.00     99.82
12:07:01 AM       all      0.11      0.00      0.25      0.00      0.00     99.64
12:08:01 AM       all      0.32      0.00      0.32      0.00      0.00     99.35
12:09:01 AM       all      0.32      0.00      0.20      0.00      0.00     99.48
12:10:01 AM       all      0.03      0.00      0.14      0.00      0.00     99.83
12:11:01 AM       all      0.04      0.00      0.20      0.00      0.00     99.76
12:12:01 AM       all      0.04      0.00      0.14      0.01      0.00     99.81
12:13:01 AM       all      0.13      0.00      0.22      0.00      0.00     99.65
12:14:01 AM       all      0.04      0.00      0.17      0.00      0.00     99.79
12:15:01 AM       all      0.06      0.00      0.15      0.00      0.00     99.79
12:16:01 AM       all      0.04      0.00      0.09      0.00      0.00     99.87
12:17:01 AM       all      0.12      0.00      0.28      0.00      0.00     99.60
12:18:01 AM       all      0.07      0.00      0.12      0.00      0.00     99.81
12:19:01 AM       all      0.14      0.00      0.23      0.00      0.00     99.63
12:20:01 AM       all      0.05      0.00      0.15      0.00      0.00     99.80
12:21:01 AM       all      0.04      0.00      0.15      0.00      0.00     99.81
12:22:01 AM       all      0.05      0.00      0.13      0.00      0.00     99.82
12:23:01 AM       all      0.13      0.00      0.26      0.00      0.00     99.61
12:24:01 AM       all      0.06      0.00      0.14      0.00      0.00     99.80
12:25:01 AM       all      0.04      0.00      0.12      0.00      0.00     99.84
12:26:01 AM       all      0.05      0.00      0.16      0.00      0.00     99.79
12:27:01 AM       all      0.13      0.00      0.24      0.00      0.00     99.63
12:28:01 AM       all      0.06      0.00      0.17      0.00      0.00     99.77
12:29:01 AM       all      0.09      0.00      0.19      0.01      0.00     99.70
12:30:01 AM       all      0.03      0.00      0.13      0.00      0.00     99.83
12:31:01 AM       all      0.07      0.00      0.20      0.00      0.00     99.73
12:32:01 AM       all      0.04      0.00      0.14      0.00      0.00     99.82

# sar -i 600 -f /var/log/sa/sa25 | head -6          ※-i オプションで 600秒=10分 指定
Linux 2.6.18-194.26.1.el5 (my41)        12/25/2010

12:00:01 AM       CPU     %user     %nice   %system   %iowait    %steal     %idle
12:10:01 AM       all      0.12      0.00      0.20      0.00      0.00     99.68
12:20:01 AM       all      0.07      0.00      0.18      0.00      0.00     99.75
12:30:01 AM       all      0.07      0.00      0.17      0.00      0.00     99.76

下記も参照ください。
CentOS 5 の sysstat のデフォルトではディスクアクセス統計が採取されない

2013-02-06追記
sar -i は、少々バグっているバージョンがあるようなので、ご注意を。基本、最新使うべし！

2017-06-14追記
sa1 と sa2 が同時に動くとエラーになる場合がある。回避方法。

# run system activity accounting tool every 1 minutes
*/1 * * * * root /usr/lib64/sa/sa1 1 1
# generate a daily summary of process accounting at 23:53
53 23 * * * root sleep 20;/usr/lib64/sa/sa2 -A

sa2 を動かす必要あるかな？とも思うのだが。

CentOS 5 の sysstat のデフォルトではディスクアクセス統計が採取されない

CentOS 5 の sysstat のデフォルトではディスクアクセス統計(sar -d)が採取されませんが、サーバ運用をしている人は、ときおりデータを見たい場合があるのではないでしょうか？

デフォルトの /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

デフォルトのまま、sar -d すると、データが利用できませんとのメッセージが表示されます。

# sar -d
Requested activities not available in file

もしディスクアクセス統計を採取したい場合は、/etc/cron.d/sysstat を次のように変更します。ついでに、採取頻度を１分毎に変更しています。１０分毎ではアラ過ぎと思う。

# run system activity accounting tool every 10 minutes
*/1 * * * * root /usr/lib64/sa/sa1 -d 1 1
# generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A

ただし、変更が有効に働くのは次の日からです。１日の途中で、/var/log/sa/saXX に項目が増えても認識してくれないようです。もちろん、消していいのなら、無理やり /var/log/sa/saXX を消せば、上記の設定が反映されたことを確認できます。ディスクアクセス統計が有効になれば、次のような出力を得ることができます。

# sar -d -p    ※ディスクデバイス名を分かりやすく表示するには -p オプションをつけます
Linux 2.6.18-194.26.1.el5 (my41)        12/23/2010

11:29:01 AM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
11:30:01 AM       sda      2.72      0.00     52.78     19.44      0.00      0.76      0.15      0.04
11:30:01 AM      sda1      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
11:30:01 AM      sda2      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
11:30:01 AM      sda3      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
11:30:01 AM      sda4      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
11:30:01 AM      sda5      2.72      0.00     52.78     19.44      0.00      0.76      0.15      0.04
11:30:01 AM      sda6      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
11:30:01 AM      sda7      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
11:30:01 AM      sda8      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
11:30:01 AM      sda9      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00

なお、CentOS 4 だと、デフォルトでディスクアクセス統計も採取されます。また、まだ出ていませんが、CentOS 6 でもデフォルト採取されるものと思います。ベースの RHEL6 のデフォルトの /etc/cron.d/sysstat は次のようになっており、ディスクアクセス統計も採取されるようになっています。

# Run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib64/sa/sa1 -S DISK 1 1
# 0 * * * * root /usr/lib64/sa/sa1 -S DISK 600 6 &
# Generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A

RHEL6 では、オプションが変わって（-d → -S DISK）しまっています。OSS の世界では、"進化のためには非互換変更もやっちゃいます"というわけでしょうし、進化も歓迎なのですが、OSS を商売にする人（わたしも）にとっては、非互換というのは面倒・トラブルのもとですね。

CentOS 5.5 の dump/restore コマンドは ext4 に非対応

CentOS 5.5 では ext4 が使えますが、１つ注意点として、dump/restore コマンドが非対応になっています。ベースの RHEL5 では、技術的理由から dump/restore の ext4 対応はしないと言っていますので、今後もおそらく対応されることはないと考えられます。バックアップに dump/restore を使うつもりで、あてが外れないようにご注意を。まあ、バックアップツールは他にも多数あるんですが・・・

https://bugzilla.redhat.com/show_bug.cgi?id=444534

2011-03-26追記
RHEL6 の dump/restore は ext4 にも対応しているので、未だリリースされませんが、CentOS 6 では ext4 に対応するはずです。もし、CentOS 5.5 以降で ext4 を使っている場合で、システムバックアップを採るということなら、CentOS 6 の iso イメージから rescue モードで起動すればいいだろうと思います。

CentOS 5 の kernel-debuginfo は複数バージョン同時インストールできないのか？

CentOS 4 までは、kernel-debuginfo を複数バージョン同時にインストールできたが、CentOS 5 では、同時インストールしようとすると rpm からはじかれてしまう。

# uname -r
2.6.18-194.26.1.el5
# ls -l kernel-debuginfo-2.6.18-194.26.1.el5.x86_64.rpm 
-rw-r--r-- 1 root root 181913978 Dec 18 13:06 kernel-debuginfo-2.6.18-194.26.1.el5.x86_64.rpm
# rpm -qlvp kernel-debuginfo-2.6.18-194.26.1.el5.x86_64.rpm | grep -v `uname -r`
何も出力なし
#

という具合なので、デバッグ用オブジェクトはちゃんとバージョン毎に分かれて格納されている。kernel-debuginfo が依存している kernel-debuginfo-common のほうに、ソースが入っているようであり、こちらがバージョン毎のディレクトリに分かれていないために、ＮＧということのようだ。

# rpm -qlp kernel-debuginfo-common-2.6.18-194.26.1.el5.x86_64.rpm | less
/usr/lib/debug
/usr/lib/debug/boot
/usr/lib/debug/lib
/usr/lib/debug/lib/modules
/usr/lib/debug/usr/src/kernels
/usr/src/debug
/usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64
/usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/arch
/usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/arch/i386
/usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/arch/i386/kernel
/usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/arch/i386/kernel/acpi
/usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/arch/i386/kernel/acpi/boot-xen.c
...

なので、単にリングバッファ、バックトレース、メモリ使用状況程度を見るのなら、kernel-debuginfo だけを --nodeps で入れてしまえばいいようだ。
なお、いつもどこだっけ？・・・となるので、2010-12 現在の kernel-debuginfo の在り処をメモしておく。
http://debuginfo.centos.org/

Fedora 14 で root でログイン

Fedora 14 のデフォルトでは、GDM から root でログインできない。
推奨されないのは承知だが、仕事がら root でログインできたほうが便利なので、Googleで検索したところ、/etc/pam.d/gdm と /etc/pam.d/gdm-password の次のエントリーをコメントアウトすればよいとのこと。先人の方に感謝。

auth required pam_succeed_if.so user != root quiet

http://old.ikoinoba.net/wiki/?Linux/Fedora/11/memo2#wbd2161a

2011-04-24追記
Fedora 15 Beta でも同様でした。

2011-09-09追記
Fedora 16 Alpha でも同様でした。

2012-06-07追記
Fedora 17 でも同様です。

NIC 交換時の CentOS における kudzu の挙動

サーバのマザーボード故障で、交換が発生した場合、 当然ながらオンボード NIC の MAC が変わってしまうが、その場合の挙動が CentOS 5 と CentOS 4 では異なっている。以下は、VMware 上で実験した結果です。

■CentOS 5 の場合は、自動的に DHCP 設定に置き換えられて、バックアップ（サフィックス.bak）が作成される。

# cd /etc/sysconfig/network-scripts/

# ls ifcfg-eth3*
ifcfg-eth3  ifcfg-eth3.bak

# cat /etc/sysconfig/network-scripts/ifcfg-eth3
# Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE]
DEVICE=eth3
BOOTPROTO=dhcp
ONBOOT=yes
HWADDR=00:0c:29:67:4d:2e

どのみち MAC を書き換えなければ、eth3 を使えないので、デスクトップ利用の場合なら、この自動処置があると便利、ということかと思います。サーバ用途だと、勝手に設定が書き換わるというこの動作は、面食らうと思うのですがね・・・。

■CentOS 4 の場合は、起動時にハードウェア（NIC）の変更を検出して、次のような画面が出る。タイムアウトが 30秒 なので、処置しないとサーバ起動のたびにこの画面が出て、30秒 遅延することになる。

30秒 以内に、キー入力（スペース等）すると、次の画面へ遷移する。

上の画面は、交換前の NIC の設定を削除していいかを尋ねているので、交換前の設定を残すには、「Keep Configuration」を選べばいい。そうすると、次の画面へ遷移する。

上の画面は、交換後の NIC の設定を行うかどうか尋ねているので、サーバ起動完了後に vi で、設定ファイル（ifcfg-ethX の HWADDR=）の MAC を書き換えるなら、「Ignore」を選べばよい。

2011-07-24追記
CentOS 6.0 の場合については、こちら を参照。

CentOS 5.5 において ext4 に kdump 出力する

CentOS 5.5 では、ext4 が使えるので、自分の管理している小規模サーバでは、全て ext4 にしてしまった。CentOS 5.5 のインストーラーでは、/ を ext4 にしてインストールしようとすると蹴られるのだが、予め、インストール CD からレスキューモードを起動して、ファイルシステムを作成してしまうことで、うまくインストールできた。本題ではないが、ext4 のファイルシステム作成手順は、次のとおり。

# mke2fs -j /dev/sda3          ※まずは、ext3 を作る

# tune4fs -O extent /dev/sda3  ※エクステントフラグを付加（ext4化する）する。これがキモ
      ※CentOS 5.5 の場合、tune4fs なので注意

# tune4fs -O flex_bg     /dev/sda3  ※その他のオプションを設定
# tune4fs -O huge_file   /dev/sda3  ※  そのうち、もう少し詳細を書こう
# tune4fs -O uninit_bg   /dev/sda3  ※
# tune4fs -O dir_nlink   /dev/sda3  ※
# tune4fs -O extra_isize /dev/sda3  ※

さて、kdump の領域に ext4 を使うには、ext3 の場合と同様に記述するのですが、次のように extra_bins の指定も必要です。これをやらないと、セカンドカーネルでダンプ採取領域をマウントする前の fsck が出来ず（fsck.ext4 が見つからないといわれる）、ダンプが失敗します。

extra_bins /sbin/fsck.ext4
ext4 LABEL=/
path /var/crash
core_collector makedumpfile -c -d 1

なお、ext3 で kdump 専用領域を作ったほうがいいのかもしれませんが、kdump のために遊ばせておくというのもと思うため、/ １個にしています。/var も分割していません。もし重要度の高い業務用サーバなら /var を独立させて、ログとダンプ置き場専用とするのが一番無難だろうと思います。

2010-12-18追記
ext4 を使う前に、こちらも確認を。

2011-03-27追記
ext4 のファイルシステム作成は、mkfs.ext4 で行えば、最初に書いたような tune4fs でのオプション設定は不要でした。

2011-08-02追記
今ごろ気がつきましたが、既に 5.6 で kexec-tools に ext4 サポートが追加されていました。
http://rhn.redhat.com/errata/RHEA-2011-0146.html
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=667966
上のような小細工をするよりも、kexec-tools をアップデートしましょう。

ThinkPad X300 のSSDで不良セクタを発見

ThinkPad X300 の内臓SSD（SAMSUNG SLCタイプ MCCOE64G8MPP-0VA 約2年使用）に不良セクタが出来てしまい。参考にデータを、ThinkPad Club の方にレポートしたのですが、ここでは、Linux (Parted MagicのブータブルCDを利用) で ddrescue と dd を使って、書き戻してみた結果を書いておきます。 書き戻しにより、代替セクタが利用されて、もうしばらく使えないかなと思ったのですが・・・

まずは、ddrescueの出力を示します。USB-HDD へ丸ごとコピーしました。

root@PartedMagic:/mnt_sdb1# ddrescue -dS /dev/sda sda.ddrescue-2010-11-20 ddrescue-2010-11-20.log


Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:    64022 MB,  errsize:    268 kB,  current rate:        0 B/s
   ipos:    55255 MB,   errors:      91,    average rate:    6813 kB/s
   opos:    55255 MB,     time from last successful read:       2 s
Finished                   
root@PartedMagic:/mnt_sdb1# 

以下は、ddrescue のログです。見方はソースをほじくらないと正確には分かりませんが。

# Rescue Logfile. Created by GNU ddrescue version 1.13
# Command line: ddrescue -dS /dev/sda sda.ddrescue-2010-11-20 ddrescue-2010-11-20.log
# current_pos  current_status
0xCDD837C00     +
#      pos        size  status
0x00000000  0x33830200  +
0x33830200  0x00000200  -
0x33830400  0x00003C00  +
0x33834000  0x00004000  -
0x33838000  0x03FF8200  +
0x37830200  0x00000200  -
0x37830400  0x00003C00  +
0x37834000  0x00004000  -
0x37838000  0x27FE8200  +
0x5F820200  0x00000200  -
0x5F820400  0x00003C00  +
0x5F824000  0x00000200  -
0x5F824200  0x00000600  +
0x5F824800  0x00000200  -
0x5F824A00  0x00000600  +
0x5F825000  0x00000200  -
0x5F825200  0x00000600  +
0x5F825800  0x00000200  -
0x5F825A00  0x00000600  +
0x5F826000  0x00000200  -
0x5F826200  0x00000600  +
0x5F826800  0x00000200  -
0x5F826A00  0x00000600  +
0x5F827000  0x00000200  -
0x5F827200  0x00000600  +
0x5F827800  0x00000200  -
0x5F827A00  0x0000C600  +
0x5F834000  0x00000200  -
0x5F834200  0x00000600  +
0x5F834800  0x00000200  -
0x5F834A00  0x00000600  +
0x5F835000  0x00000200  -
0x5F835200  0x00000600  +
0x5F835800  0x00000200  -
0x5F835A00  0x00000600  +
0x5F836000  0x00000200  -
0x5F836200  0x00000600  +
0x5F836800  0x00000200  -
0x5F836A00  0x00000600  +
0x5F837000  0x00000200  -
0x5F837200  0x00000600  +
0x5F837800  0x00000200  -
0x5F837A00  0x9FFE8800  +
0xFF820200  0x00000200  -
0xFF820400  0x00003C00  +
0xFF824000  0x00004000  -
0xFF828000  0x0000C000  +
0xFF834000  0x00004000  -
0xFF838000  0xF9FE8200  +
0x1F9820200  0x00000200  -
0x1F9820400  0x00003C00  +
0x1F9824000  0x00004000  -
0x1F9828000  0x0000C000  +
0x1F9834000  0x00004000  -
0x1F9838000  0xFBFE8200  +
0x2F5820200  0x00000200  -
0x2F5820400  0x00003C00  +
0x2F5824000  0x00004000  -
0x2F5828000  0x0000C000  +
0x2F5834000  0x00004000  -
0x2F5838000  0x261FF8200  +
0x557830200  0x00000200  -
0x557830400  0x00003C00  +
0x557834000  0x00004000  -
0x557838000  0xDDFE8200  +
0x635820200  0x00000200  -
0x635820400  0x00003C00  +
0x635824000  0x00000200  -
0x635824200  0x00000600  +
0x635824800  0x00000200  -
0x635824A00  0x00000600  +
0x635825000  0x00000200  -
0x635825200  0x00000600  +
0x635825800  0x00000200  -
0x635825A00  0x00000600  +
0x635826000  0x00000200  -
0x635826200  0x00000600  +
0x635826800  0x00000200  -
0x635826A00  0x00000600  +
0x635827000  0x00000200  -
0x635827200  0x00000600  +
0x635827800  0x00000200  -
0x635827A00  0x0000C600  +
0x635834000  0x00000200  -
0x635834200  0x00000600  +
0x635834800  0x00000200  -
0x635834A00  0x00000600  +
0x635835000  0x00000200  -
0x635835200  0x00000600  +
0x635835800  0x00000200  -
0x635835A00  0x00000600  +
0x635836000  0x00000200  -
0x635836200  0x00000600  +
0x635836800  0x00000200  -
0x635836A00  0x00000600  +
0x635837000  0x00000200  -
0x635837200  0x00000600  +
0x635837800  0x00000200  -
0x635837A00  0x155FE8800  +
0x78B820200  0x00000200  -
0x78B820400  0x00003C00  +
0x78B824000  0x00000200  -
0x78B824200  0x00000600  +
0x78B824800  0x00000200  -
0x78B824A00  0x00000600  +
0x78B825000  0x00000200  -
0x78B825200  0x00000600  +
0x78B825800  0x00000200  -
0x78B825A00  0x00000600  +
0x78B826000  0x00000200  -
0x78B826200  0x00000600  +
0x78B826800  0x00000200  -
0x78B826A00  0x00000600  +
0x78B827000  0x00000200  -
0x78B827200  0x00000600  +
0x78B827800  0x00000200  -
0x78B827A00  0x0000C600  +
0x78B834000  0x00000200  -
0x78B834200  0x00000600  +
0x78B834800  0x00000200  -
0x78B834A00  0x00000600  +
0x78B835000  0x00000200  -
0x78B835200  0x00000600  +
0x78B835800  0x00000200  -
0x78B835A00  0x00000600  +
0x78B836000  0x00000200  -
0x78B836200  0x00000600  +
0x78B836800  0x00000200  -
0x78B836A00  0x00000600  +
0x78B837000  0x00000200  -
0x78B837200  0x00000600  +
0x78B837800  0x00000200  -
0x78B837A00  0x1E9FE8800  +
0x975820200  0x00000200  -
0x975820400  0x00003C00  +
0x975824000  0x00000200  -
0x975824200  0x00000600  +
0x975824800  0x00000200  -
0x975824A00  0x00000600  +
0x975825000  0x00000200  -
0x975825200  0x00000600  +
0x975825800  0x00000200  -
0x975825A00  0x00000600  +
0x975826000  0x00000200  -
0x975826200  0x00000600  +
0x975826800  0x00000200  -
0x975826A00  0x00000600  +
0x975827000  0x00000200  -
0x975827200  0x00000600  +
0x975827800  0x00000200  -
0x975827A00  0x0000C600  +
0x975834000  0x00000200  -
0x975834200  0x00000600  +
0x975834800  0x00000200  -
0x975834A00  0x00000600  +
0x975835000  0x00000200  -
0x975835200  0x00000600  +
0x975835800  0x00000200  -
0x975835A00  0x00000600  +
0x975836000  0x00000200  -
0x975836200  0x00000600  +
0x975836800  0x00000200  -
0x975836A00  0x00000600  +
0x975837000  0x00000200  -
0x975837200  0x00000600  +
0x975837800  0x00000200  -
0x975837A00  0x1D7FE8800  +
0xB4D820200  0x00000200  -
0xB4D820400  0x00003C00  +
0xB4D824000  0x00004000  -
0xB4D828000  0x0000C000  +
0xB4D834000  0x00004000  -
0xB4D838000  0x11BFF8200  +
0xC69830200  0x00000200  -
0xC69830400  0x00003C00  +
0xC69834000  0x00004000  -
0xC69838000  0x73FE8200  +
0xCDD820200  0x00000200  -
0xCDD820400  0x00003C00  +
0xCDD824000  0x00004000  -
0xCDD828000  0x0000C000  +
0xCDD834000  0x00004000  -
0xCDD838000  0x20A91E000  +

このようにエラーのオンパレードです。
そして書き戻しのログです。

root@PartedMagic:/mnt_sdb1# dd if=sda.ddrescue-2010-11-20 bs=4096 of=/dev/sda oflag=direct,dsync
15630678+0 records in
15630678+0 records out
64023257088 bytes (64 GB) copied, 14007.1 s, 4.6 MB/s
root@PartedMagic:/mnt_sdb1# 

書き戻しの際にはエラーは出ませんでした。
その後、Windows XP を起動して、chkdsk をやったのですが、まったく効果なしで虫食い状態でした。以上の試行から悟ったことは、、、恐ろしいことですが、書き込みではエラーが出ず、読み込みでエラーになるということです。つまり、しっかり保存したつもりが、実際にはデータ損失してしまう場合がある状態になってしまっている。ということです。

2010-12-01追記
もう一つ気がついたのでメモ。HDD の不良セクタとの違いにも注意する必要がありそうです。SSDの場合には、ウェアレベリングの負の作用なのか、不良部分の場所が揺れるので、何回 CHKDSK /R をやっても、不良セクタをファイルシステムから除外できないようです。
（もっとも、このあたりは SSD のベンダーにより制御が違うだろうと思いますが）

HDD の不良セクタなら、ファイルシステムの不良セクタリストに登録されて、そのセクタへアクセスしないようになります。
（これもファイルシステム次第でしょうが、ext2/3/4, ntfs はそのはず）

2012-09-02追記
SecureErase という操作のことを知り、死蔵していたこの記事の SSD にも適用してみたら、見かけ上かもしれませんが、不良部分が消えました！
SecureErase 実行前は、次のような状態でした。HDDSCAN の結果です。

そして、SecureErase 後がこちらです。

実験も兼ねて、この SSD を、ZFS の L2ARC 用として、再利用開始しました。
L2ARC というのはセカンドキャッシュであり、ZFS では全てのブロックがチェックサム確認されるので、もし壊れたキャッシュを読んだり、I/O エラーとなったとしても、その後の迂回処理で、ストレージプール (HDD 集合の管理単位) から読まれるはずです。なお、用心のため、この SSD を L2ARC として接続したのは、最悪は壊れてしまってもかまわないもの (CentOS や Fedora の ISO イメージ) が入っている領域です。

KVM 上に RH7.3 を p2v

古いサーバ（RH7.3）を、最新サーバ（CentOS5.5 x86_64）上の KVM に p2v しようとして調査＆実験中。
RH7.3 は、Web サーバとして使っている程度なのだが、これまで７年ほど安定して動いていたし、全く新しくサーバを作るというのも面倒（と思えるだけ？）なので、そのまま丸ごと p2v しようと調査している。
まずは、CentOS5.5 の KVM 上で、RH7.3 がどの程度動くものか調査。RH7.3 を最小インストールしたところ、まあ普通に動いた。が、どうにもI/O性能が低い。これは、KVM の設定で、writeback に変更して解決。

    <disk type='block' device='disk'>
      <driver name='qemu' cache='writeback'/>
      <source dev='/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part5'/>
      <target dev='hda' bus='ide'/>
    </disk>

次に、パワーオフ（shutdown -h now）がうまくいかず。ブートオプション apm=power_off を追加して解決。ここで、apm=power_off,realmode_power_off のように、後ろに realmode_power_off をつけてしまうと、パワーオフ（shutdown -h now）をやっても、リブートしてしまうので注意。

title Red Hat Linux (2.4.20-46.7.legacysmp)
        root (hd0,0)
        kernel /vmlinuz-2.4.20-46.7.legacysmp ro root=/dev/hda2 apm=power_off
        initrd /initrd-2.4.20-46.7.legacysmp.img

ちなみに、KVM ゲストが RHEL3 の場合も、これでパワーオフできるようになります。

2011-02-19追記
VMware 上で RHEL3 を動かす場合にも、apm=power_off は効きます。わたしが利用しているのは、VMware Server 1.0 と VMware Player です。

2011-03-27追記
realmode_power_off を打ち間違えて、real_mode_power_off と記載していましたので、修正しました。なお、この辺のパラメータに対応するコードは、arch/i386/kernel/apm.c にあります。

static int __init apm_setup(char *str)
{
...
                if ((strncmp(str, "power-off", 9) == 0) ||
                    (strncmp(str, "power_off", 9) == 0))
                        power_off = !invert;
                if ((strncmp(str, "allow-ints", 10) == 0) ||
                    (strncmp(str, "allow_ints", 10) == 0))
                        apm_info.allow_ints = !invert;
                if ((strncmp(str, "broken-psr", 10) == 0) ||
                    (strncmp(str, "broken_psr", 10) == 0))
                        apm_info.get_power_status_broken = !invert;
                if ((strncmp(str, "realmode-power-off", 18) == 0) ||
                    (strncmp(str, "realmode_power_off", 18) == 0))
                        apm_info.realmode_power_off = !invert;
...

2014-05-02追記
その後、実際に引っ越して一年以上運用しているが、問題なし。

Fake RAID

仕事で使う新しいサーバに、今まで使ったことがなかった LSI Software MegaRAID という所謂 SATA RAID が載っていて、Linux のソフトRAID(md)とどちらを使うか迷っていました。そもそも、SATA RAID って何だ？どこまでハードでやってくれるのか？というところからして知識が無く、次の情報を読んでやっとイメージがつかめました。

http://itpro.nikkeibp.co.jp/article/Keyword/20070824/280335/

http://h50146.www5.hp.com/products/software/oe/linux/mainstream/support/faq_hard/hard_ata_raid.html#ahasoftware

http://2chnull.info/r/linux/1208263754/201-300

これらを読んで、複数の HDD の集合を RAID として BIOS に見せる機能を、ハードウェアが提供してくれる。同様に OS にも RAID として認識できるようなメタデータを見せてくれる。ということかなと理解しました。試したところ、SATA RAID の場合、Linux 上からは dmraid として扱われ、デバイス名がやたらに長くなるようでした。デバイス名がやたらに長くなるのが運用上耐えられないのと、md なら２台でも RAID10 (READ のみストライプ) が使えるようなので、そちらにすることにしました。２台で RAID10 を構成するには、

# mdadm -C /dev/md1 -l 10 -p f2 -n 2 /dev/sd[ab]2

のようにする。ただし、GRUB は RAID10 を扱えないようなので、/boot だけは RAID1 にする必要があります。それから、１台目の HDD が壊れると、ブート出来なくなるので、２台目の HDD の MBR のセットアップも必要です。
次のMIRACLE LINUXさんのFAQが参考になります。

http://www.miraclelinux.com/technet/faq/data/00080.html

2010-10-03追記
mdadm の -p f2 ですが、READ が最速になる指定とのこと。下記に、わかりやすい説明があります。感謝。

http://hellokitty68.main.jp/wiki/Linux_Software_RAID10

2010-10-06追記
dmraid の場合に、デバイス名がどのように見えるのか、試しにインストールしたときの mount の出力を貼っておきます。CentOS5.5 で試した際のもの。

# mount
/dev/mapper/ddf1_4c53492020202020808627c3000000004711471100001450p2 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/mapper/ddf1_4c53492020202020808627c3000000004711471100001450p1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

bashによる文字列置換が極端に非効率

bashには、文字列置換を行う機能が用意されており、便利に利用させてもらっています。しかし、これが非常に効率が悪いことがあることを知りました。サンプルプログラムは、次の通りです。
VAR の中の pattern を削除する ${VAR//patern} という書き方が遅い。

#!/bin/bash
# str_replace_perf.bash

#
# prepare 1000 strings of 6 digits
#
TEST_LIST=`seq 100100 100 200000`
echo $TEST_LIST | wc

#
# delete "150000"
#
T0=$SECONDS
A=${TEST_LIST//150000}
T1=$SECONDS
B=`echo $TEST_LIST | sed s/150000//g`
T2=$SECONDS

#
# results
#
echo T1-T0=$((T1-T0))
echo T2-T1=$((T2-T1))

# verify
echo $A | md5sum
echo $B | md5sum

このサンプルスクリプトでは、sed と速さを比較しています。
T1-T0 が bash で処理した場合の経過時間。T2-T1 が sed で同様の処理をした場合の経過時間。わたしのマシンでの実行結果は次の通りです。

[root@fedora14 ~]# cat /etc/redhat-release 
Fedora release 14 (Branched)
[root@fedora14 ~]# uname -r
2.6.35-0.57.rc6.git1.fc14.x86_64
[root@fedora14 ~]# bash --version
GNU bash, version 4.1.7(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
[root@fedora14 ~]# ./str_replace_perf.bash 
      1    1000    7000
T1-T0=10
T2-T1=0
de028ddb26bdd0b5aa062b1b8e753665  -
de028ddb26bdd0b5aa062b1b8e753665  -

上はサンプルですが、実際にこのボトルネックにハマって、修正が必要になった物件がありました。
Google で似たような話しが無いかはしばらく探したものの、見つかりませんでしたので、なんとか将来改善されることを期待して、bug-bash@gnu.orgへ連絡しました。

2010-09-25追記
早速、メンテナーの方から返事をもらいました。感謝。
多バイト文字サポートに起因するが、次のバージョン 4.2 に、修正を取り込む予定になっているとのことで、修正作業も既に終えているそうです。
なお、上記（多バイト文字サポートに起因）をヒントに、サンプルスクリプトを実行する前に、LANG=C を設定したところ、同じマシンでのスクリプト実行結果が T1-T0=1 に短縮されることを確認しました。

[root@fedora14 ~]# echo $LANG
ja_JP.UTF-8
[root@fedora14 ~]# ./str_replace_perf.bash 
      1    1000    7000
T1-T0=9
T2-T1=0
de028ddb26bdd0b5aa062b1b8e753665  -
de028ddb26bdd0b5aa062b1b8e753665  -
[root@fedora14 ~]# LANG=C
[root@fedora14 ~]# ./str_replace_perf.bash 
      1    1000    7000
T1-T0=1
T2-T1=0
de028ddb26bdd0b5aa062b1b8e753665  -
de028ddb26bdd0b5aa062b1b8e753665  -

2011-03-03追記
少し遅れましたが、先月 bash-4.2 がリリース済みであることを知り、さっそく試してみたところ、劇的に速くなっていました。メンテナー様、ありがとうございます。
なお、以前とは別のマシンで確認を行っています。

[root@fedora14 ~]# uname -a
Linux fedora14 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
[root@fedora14 ~]# echo $LANG
ja_JP.UTF-8
[root@fedora14 ~]# rpm -q bash
bash-4.1.7-3.fc14.x86_64
[root@fedora14 ~]# time ./str_replace_perf.bash 
      1    1000    7000
T1-T0=3
T2-T1=0
de028ddb26bdd0b5aa062b1b8e753665  -
de028ddb26bdd0b5aa062b1b8e753665  -

real    0m3.839s
user    0m3.799s
sys     0m0.020s
[root@fedora14 ~]# rpm -Uvh bash-4.2.0-2.fc15.x86_64.rpm 
警告: bash-4.2.0-2.fc15.x86_64.rpm: ヘッダ V3 RSA/SHA256 Signature, key ID 069c8460: NOKEY
準備中...                ########################################### [100%]
   1:bash                   ########################################### [100%]
[root@fedora14 ~]# time ./str_replace_perf.bash 
      1    1000    7000
T1-T0=0
T2-T1=0
de028ddb26bdd0b5aa062b1b8e753665  -
de028ddb26bdd0b5aa062b1b8e753665  -

real    0m0.028s
user    0m0.014s
sys     0m0.011s

オプション解析 (getoptsとgetoptの使い分け)

この話題はきっとポピュラーで、ネット上に多数の情報があるものと思いますが、、、

これまで、bash スクリプトでオプション解析をする際には、bash 組み込みコマンドのgetopts を使っていて、それで十二分と思っていました。しかし、getopts だと、コマンドラインの後半でオプションを指定できないことに気がつきました。 具体的には、

Usage: command.bash [-a] [-d dir] item1 item2 ...

のような構文の場合に、-d dir を item の後ろに指定しても、認識されません。（もちろん、工夫すればできそうではありますが）

そこで、調べたところ、外部コマンドの getopt なら期待通り処理してくれることを知りました。自分の中の整理のため、テンプレートを作りました。

まずは、getopts 版。いつもこのパターンを使ってました。

#!/bin/bash
#
# getopts-template.bash (use builtin getopts)
#
export LANG=C
usage_exit() {
        echo "Usage: getopts-template.bash [-a] [-d dir] item1 item2 ..." 1>&2
        exit 1
}
#
# Options
#
echo "$@"       ####DEBUG
while getopts ":ad:h" GETOPTS
do
  case $GETOPTS in
  a)    A_FLAG=yes
        ;;
  d)    OUTDIR=$OPTARG
        ;;
  h)    usage_exit
        ;;
  *)    usage_exit
        ;;
  esac
done
#
shift $((OPTIND - 1))
#
echo \$#=$#             ####DEBUG
echo \$@="$@"           ####DEBUG
echo A_FLAG=$A_FLAG     ####DEBUG
echo OUTDIR=$OUTDIR     ####DEBUG

次に、getopt 版です。

#!/bin/bash
#
# getopt-template.bash (use getopt utility)
#
export LANG=C
usage_exit() {
        echo "Usage: getopt-template.bash [-a] [-d dir] item1 item2 ..." 1>&2
        exit 1
}
#
# Options
#
echo "$@"       ####DEBUG
GETOPT=`getopt -q -o ad:h -- "$@"` ; [ $? != 0 ] && usage_exit
eval set -- "$GETOPT"
echo "$@"       ####DEBUG
while true
do
  case $1 in
  -a)   A_FLAG=yes      ; shift
        ;;
  -d)   OUTDIR=$2       ; shift 2
        ;;
  -h)   usage_exit
        ;;
  --)   shift ; break
        ;;
  *)    usage_exit
        ;;
  esac
done
#
echo \$#=$#             ####DEBUG
echo \$@="$@"           ####DEBUG
echo A_FLAG=$A_FLAG     ####DEBUG
echo OUTDIR=$OUTDIR     ####DEBUG

こちらの、getopt 版であれば、次のように -d オプションの指定を後半に行うことができます。

# ./getopt-template.bash item1 item2 -d dir
item1 item2 -d dir
-d dir -- item1 item2
$#=2
$@=item1 item2
A_FLAG=
OUTDIR=dir

一方、getopts の場合には、次のようになってしまいます。

# ./getopts-template.bash item1 item2 -d dir
item1 item2 -d dir
$#=4
$@=item1 item2 -d dir
A_FLAG=
OUTDIR=

2010-09-25追記
まとめを書き忘れていました。getopts のほうがスッキリすると思うので、itemが不要な場合（将来も不要かどうかも一考はしつつ）は、getoptsで書き、item 指定がある構文を使う場合には、getopt を使う。というガイドラインでやっていこうと思います。

2011-02-13追記
下記も参照ください。ロングオプションの場合です。
getoptによるロングオプション解析

2011-08-31追記
perl の場合についても書きましたので、興味があるようでしたら、参照ください。
perl でオプション解析

2012-05-20追記
Python の場合についても書きました。
Python でオプション解析

perl 5.12

少し遅れをとってしまいましたが、Fedora 14 Alpha を試しました。 このバージョンでは、perl が 5.12 にアップしていて、手持ちのスクリプトを試したら、一部動かなくなっていました。 調べたところ、split した結果が @_ に入ることを期待したコードがNGでした。ラクダ本VOLUME 2 28章 特殊変数によると、旧式の機能なので使うなとのこと。 実際にやっちゃっていたコードは次のうようなものです。

...
  split("\n", $temp) ;
  return @_ ;
}

これを、

...
  return split("\n", $temp) ;
}

と修正しました。今考えれば、なぜ、分割していたのかと思えますが、perl の理解が足りなかったということですね。

kdump に lzop を使う方法

kdump にはダンプファイルを圧縮する設定があり、普通は core_collector ディレクティブに makedumpfile -c を指定するという方法をとる。ただ、圧縮処理には結構な時間がかかり、これを短縮する方法はないかと考えてみた。

makedumpfile -c を指定した場合の initrd内のinit には、次のような記述が埋め込まれる。

mount -t ext3 $DUMPDEV /mnt
if [ $? == 0 ]
then
  mkdir -p /mnt///127.0.0.1-$DATE
  VMCORE=/mnt///127.0.0.1-$DATE/vmcore
  export VMCORE
  makedumpfile -c /proc/vmcore $VMCORE-incomplete >/dev/null

つまるところ core_collector に指定するフィルタプログラムは cp のシンタックスを満たせば良いようだ。 数ある圧縮プログラムの中で、高速であることを特徴とするものに lzop というプログラムがあり、これを使いたい。ただ、コマンドラインオプションを細工しても、cp のシンタックスを満たすようにはできないので、一皮かぶせる。

#! /sbin/busybox msh
/usr/bin/lzop -o $2 $1

こいつを、/etc/kdump.conf に次のような形で指定する。

ext3 LABEL=/1
path /var/crash
extra_bins /usr/bin/lzop /usr/bin/lzop.copy
core_collector lzop.copy

そうすると、initrd 内に lzop 関連のファイルが全部入る。

# zcat /boot/initrd-2.6.18-194.el5kdump.img | cpio -tv | grep lzo
-rwxr-xr-x   1 root     root       125672 Aug 31 23:19 usr/lib64/liblzo2.so.2
-rwxr-xr-x   1 root     root           44 Aug 31 23:19 usr/bin/lzop.copy
-rwxr-xr-x   1 root     root        67288 Aug 31 23:19 usr/bin/lzop
17070 blocks

initrd内のinitは次のように展開される。

mount -t ext3 $DUMPDEV /mnt
if [ $? == 0 ]
then
  mkdir -p /mnt//var/crash/127.0.0.1-$DATE
  VMCORE=/mnt//var/crash/127.0.0.1-$DATE/vmcore
  export VMCORE
  lzop.copy /proc/vmcore $VMCORE-incomplete >/dev/null

これでうまいこと、lzop 圧縮でダンプファイルが生成できました。

# pwd
/var/crash/127.0.0.1-2010-08-31-23:27:08
# file vmcore 
vmcore: lzop compressed data - version 1.020, LZO1X-1, os: Unix

gzip や bzip2 でも、同様にできるものと思いますが、速度の面から考えて、有用なのは lzop だけなのではと思います。
なお、lzop は RHEL6 Beta2 には含まれてましたが、RHEL5 には含まれていませんので、rpmfind などから拾ってくる必要があります。

2010-12-05追記
lzop で採取されたダンプの参照方法と、lzop を用いた場合の効果を書いていなかったので、まとめたいと思います。
まず、lzop で採取されたダンプの解凍方法とダンプ参照方法。

# ls -l vmcore
-r-------- 1 root root 922628641 Dec  5 11:50 vmcore.lzo

# file vmcore 
vmcore: lzop compressed data - version 1.020, LZO1X-1, os: Unix

# mv vmcore vmcore.lzo

# lzop -d vmcore.lzo 

# ls -l vmcore
-r-------- 1 root root 4122392804 Dec  5 11:50 vmcore

# crash /boot/System.map-2.6.18-194.el5 /usr/lib/debug/lib/modules/2.6.18-194.el5/vmlinux vmcore

  SYSTEM MAP: /boot/System.map-2.6.18-194.el5                          
DEBUG KERNEL: /usr/lib/debug/lib/modules/2.6.18-194.el5/vmlinux (2.6.18-194.el5)
    DUMPFILE: vmcore
        CPUS: 2
        DATE: Sun Dec  5 11:49:50 2010
      UPTIME: 00:43:27
LOAD AVERAGE: 2.03, 1.71, 1.33
       TASKS: 144
    NODENAME: my39
     RELEASE: 2.6.18-194.el5
     VERSION: #1 SMP Fri Apr 2 14:58:14 EDT 2010
     MACHINE: x86_64  (1196 Mhz)
      MEMORY: 3.9 GB
       PANIC: "SysRq : Trigger a crashdump"
         PID: 7544
     COMMAND: "bash"
        TASK: ffff81011dbf7040  [THREAD_INFO: ffff81010fdf2000]
         CPU: 1
       STATE: TASK_RUNNING (SYSRQ)

crash> 

次に同じマシンで makedumpfile -c -d 1 で採取したダンプの情報です。こちらの場合は、圧縮したまま crash に渡すことができます。

# ls -l vmcore 
-rw------- 1 root root 848124021 Dec  5 12:03 vmcore

# file vmcore 
vmcore: data

# crash /boot/System.map-2.6.18-194.el5 /usr/lib/debug/lib/modules/2.6.18-194.el5/vmlinux vmcore

  SYSTEM MAP: /boot/System.map-2.6.18-194.el5                          
DEBUG KERNEL: /usr/lib/debug/lib/modules/2.6.18-194.el5/vmlinux (2.6.18-194.el5)
    DUMPFILE: vmcore  [PARTIAL DUMP]
        CPUS: 2
        DATE: Sun Dec  5 11:56:53 2010
      UPTIME: 00:04:52
LOAD AVERAGE: 0.23, 0.29, 0.13
       TASKS: 144
    NODENAME: my39
     RELEASE: 2.6.18-194.el5
     VERSION: #1 SMP Fri Apr 2 14:58:14 EDT 2010
     MACHINE: x86_64  (1197 Mhz)
      MEMORY: 3.9 GB
       PANIC: "SysRq : Trigger a crashdump"
         PID: 6310
     COMMAND: "bash"
        TASK: ffff8101371d07e0  [THREAD_INFO: ffff81013ad80000]
         CPU: 1
       STATE: TASK_RUNNING (SYSRQ)

crash> help -n | grep dump_level
          dump_level: 1 (0x1) (DUMP_EXCLUDE_ZERO)

lzop で採取した場合と、makedumpfile -c -d 1 で採取した場合のデータを整理すると、次のようになります。

■ lzop で採取した場合
ダンプ採取所要時間：1分22秒（kdump_post を使ってタイムスタンプを記録して測定）
ダンプファイルサイズ：922628641

■ makedumpfile -c -d 1 で採取した場合
ダンプ採取所要時間：6分34秒（kdump_post を使ってタイムスタンプを記録して測定）
ダンプファイルサイズ：848124021

このように、ダンプファイルサイズが少し大きくなる程度で、ダンプ採取時間が大幅に短縮（＝ダウンタイムが大幅に短縮）でき、LZO の威力（高速圧縮性能）が発揮された結果となりました。 最後になりましたが、実験は、ThinkPad X300 メモリ4GB ＋ CentOS 5.5 x86_64 で行いました。環境情報を示します。

# uversion 
CentOS release 5.5                      647818J

BIOS version  : 7TET36WW (1.10 )  05/11/2009
System serial : xxxxxxx

CPU model  : Intel(R) Core(TM)2 Duo CPU     L7100  @ 1.20GHz
Processors : 2  (1 sockets, 2 cores per CPU, HT: not supported or disabled)

Memory : 3780 MB

Linux : 2.6.18-194.el5  x86_64  (my39)

この環境で、システム起動直後にテストデータ（Webサーバを想定してテキストデータ）でキャッシュを満タンにした状態でダンプ採取して、比較しました。

2011-06-19追記
dumpコマンドのLZO圧縮オプション
よければ、こちらも、参照ください。

2011-06-26追記
EPEL というのがあることを知り、確かめてみたら、lzop も入ってました。
http://download.fedora.redhat.com/pub/epel/5/

2012-11-25追記
64bit版の CentOS 6 または RHEL6 であれば、lzop が収録されています。

2013-12-07追記
CentOS 6.5 で、makedumpfile (kexec-tools パッケージに収録) に -l オプション (LZO 圧縮サポート) が追加されましたので、上のような小細工は必要なくなりました。同時に Snappy のサポート (-p オプション) も追加されています。どちらが効果的かは、サーバの使い方によるかと思います。

ThinkPad X301 のLED制御

仕事仲間から教わったのですが、ThinkPad の各種LEDは /proc/acpi/ibm/led から制御できるらしく、少し調べてみました。

# cat /etc/redhat-release 
Fedora release 13 (Goddard)
# cat /proc/acpi/ibm/led 
status:         supported
commands:        on,  off,  blink ( is 0-15)

つまりは、この /proc/acpi/ibm/led に、"0 blink" などの文字列を書き込めばいいということがわかります。0～15 までの数字で、どの LED かを指定するようです。それで、

# for i in `seq 0 15`; do echo $i; echo $i blink > /proc/acpi/ibm/led; done

とやってみると、電源ボタンの LED (白) とその隣のサスペンド LED (緑) が点滅を始めることが確認できました。対応する LED 番号は、それぞれ 0 と 7 です。残念ですが、ThinkVantage ボタンの LED (青) には変化ありませんでした・・・(-.- 残念。ドライバのソースを見てみると、

   5019 static const char * const tpacpi_led_names[TPACPI_LED_NUMLEDS] = {
   5020         /* there's a limit of 19 chars + NULL before 2.6.26 */
   5021         "tpacpi::power",
   5022         "tpacpi:orange:batt",
   5023         "tpacpi:green:batt",
   5024         "tpacpi::dock_active",
   5025         "tpacpi::bay_active",
   5026         "tpacpi::dock_batt",
   5027         "tpacpi::unknown_led",
   5028         "tpacpi::standby",
   5029         "tpacpi::dock_status1",
   5030         "tpacpi::dock_status2",
   5031         "tpacpi::unknown_led2",
   5032         "tpacpi::unknown_led3",
   5033         "tpacpi::thinkvantage",
   5034 };
   5035 #define TPACPI_SAFE_LEDS        0x1081U
"drivers/platform/x86/thinkpad_acpi.c"

というように ThinkVantage ボタンの LED には、12 が割り当てられているようなのですが、

# echo 12 on > /proc/acpi/ibm/led

とやっても反応なしでした。ボタンだという違いがあるので、光るためには、さらに条件が必要なのだろうか。ねむいので、また今度調べてみます。

bash で扱える整数の上限

bash で扱える整数の上限(limit)を調べる必要があり、小さなスクリプトを書きました。最近は、32bit 版の Linux ディストリビューションでも LLONG_MAX まで扱えるようです。

# cat /etc/redhat-release 
CentOS release 4.8 (Final)
# uname -a
Linux centos 2.6.9-89.0.18.ELsmp #1 SMP Tue Dec 15 14:25:00 EST 2009 i686 i686 i386 GNU/Linux
# bash --version
GNU bash, version 3.00.15(1)-release (i686-redhat-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.

# cat test_int_limit.bash 
#!/bin/bash

test_int_limit() {
        local -i i=2147483646
        echo -e "INT_MAX-1 = "$i
        let i++
        echo -e "INT_MAX   = "$i
        let i++
        echo -e "INT_MAX+1 = "$i
echo
        i=4294967294
        echo -e "ULONG_MAX-1 = "$i
        let i++
        echo -e "ULONG_MAX   = "$i
        let i++
        echo -e "ULONG_MAX+1 = "$i
echo
        i=9223372036854775806
        echo -e "LLONG_MAX-1 = "$i
        let i++
        echo -e "LLONG_MAX   = "$i
        let i++
        echo -e "LLONG_MAX+1 = "$i
echo
}

test_int_limit

# ./test_int_limit.bash 
INT_MAX-1 = 2147483646
INT_MAX   = 2147483647
INT_MAX+1 = 2147483648

ULONG_MAX-1 = 4294967294
ULONG_MAX   = 4294967295
ULONG_MAX+1 = 4294967296

LLONG_MAX-1 = 9223372036854775806
LLONG_MAX   = 9223372036854775807
LLONG_MAX+1 = -9223372036854775808

2011-12-28追記
tcsh および ksh についても調べましたので、それぞれ下記を参照ください。
ksh で扱える整数の上限
tcsh で扱える整数の上限

ThinkPad X301 をメモリ８GBに増強

X301（2777RM5）のカタログスペックでは、4GBまでとなっているが、ThinkPad Club などで8GBでの動作報告があったので、昨日、秋葉原の某店にて、この日最安値のMicron PC3-8500 4GB を２枚購入してきて増設（2GB→8GB）しました。特にトラブルなく成功し、これで仮想マシンを動かすのに十二分なサイズになりました。

# uversion 
Red Hat Enterprise Linux Server release 6.0 Beta    2777RM5

BIOS version  : 6EET50WW (3.10 )  03/16/2010
System serial : xxxxxxx

CPU model  : Intel(R) Core(TM)2 Duo CPU     U9400  @ 1.40GHz
Processors : 2  (1 sockets, 2 cores per CPU, HT: not supported or disabled)

Memory : 7832 MB

Linux : 2.6.32-37.el6.x86_64  x86_64  (my41)

# grep Crash /proc/iomem 
  02000000-05ffffff : Crash kernel

ご覧のように kdump に 64MB 割り当ています（crashkernel=64M）が、7832MB だと 296MB ほど少ない計算になります。が、これは GA に割かれているからということらしいです。dmesg の中の次の箇所から、なんとなくわかる。まあ、全体からすればゴミみたいなもんですが、いちおう納得してすっきりしておきます。

# dmesg
...
Linux agpgart interface v0.103
agpgart-intel 0000:00:00.0: Intel GM45 Chipset
agpgart-intel 0000:00:00.0: detected 32764K stolen memory
ACPI: Battery Slot [BAT0] (battery present)
agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000...

ところで、わたしはメモリを買ってきたら必ず memtest86 または memtest86+ を流してチェックをかけます。今回も RHEL6 Beta2 の DVD から実行できる memtest86+ を利用しました。エラーなしで終了しています。さすがに 8GB ということで、2時間ぐらいかかりました。精神衛生上よろしくないので、かならず儀式としてやっていることです。 ちょっと話題が飛びますが、SSD や HDD も Windows 上の hddscan というソフトで初期導入時に必ずチェックしてから使い始めます。古い X300 のほうの SSD は、少々不良ブロックが出来てしまってます。その件については、また今度書こうと思います。

ThinkPad X301 で RHEL6 Beta2

RHEL6 Beta2 が出たので早速 X301 にインストールした。 もっぱら Windows から Poderosa で、サーバへリモートアクセスするという使い方しかしていなかったため、デスクトップ Linux についての知識が不足中。 自分のために、メモを残しておく。

・無線LAN
Linux で無線LANは初めてだったが、とりたてて苦労せずに接続できた。 ちなみに、ニンテンドー WiFi ネットワークアダプターを使ってます。安かったので、DS 接続用も兼ねて導入したもの。周期的にハングする（ルーティングができなくなり管理画面も接続不可になる）のですが、１ヶ月ぐらいはもつので、リセット運用してます。サポートに問い合わせる時間ももったいないので。

・トラックポイント
デフォルトではスピードが遅すぎるので調整したかったが、Mouse Preferences / Pointer Speed では制御できず、ネットで調べたところ、次の /sys ファイルで調整できるようです。先人の方に感謝。

# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.0 Beta (Santiago)
# uname -r
2.6.32-37.el6.x86_64
# cat /sys/devices/platform/i8042/serio1/serio2/speed 
160
# cat /sys/devices/platform/i8042/serio1/serio2/sensitivity 
224

数字は、自分好みに設定後の値です。デフォルトは次の箇所で定義されてます。

    245 static void trackpoint_defaults(struct trackpoint_data *tp)
    246 {
    247         tp->press_to_select = TP_DEF_PTSON;
    248         tp->sensitivity = TP_DEF_SENS;
    249         tp->speed = TP_DEF_SPEED;
    250         tp->reach = TP_DEF_REACH;
"kernel-2.6.32-37.el6/linux-2.6.32.x86_64/drivers/input/mouse/trackpoint.c"
    108 /*
    109  * Default power on values
    110  */
    111 #define TP_DEF_SENS             0x80
    112 #define TP_DEF_INERTIA          0x06
    113 #define TP_DEF_SPEED            0x61
    114 #define TP_DEF_REACH            0x0A
"kernel-2.6.32-37.el6/linux-2.6.32.x86_64/drivers/input/mouse/trackpoint.h"

ログイン時の自動設定は、別途行ってこのBlogにメモする予定。現在は、設定シェルを手動で実行しています。

2010-08-22追記
結局は最も簡単な /etc/rc.d/rc.local へ追記するという対処にしています。hotplug でと思ってましたが。

・タッチパッド
比較的嫌われもののタッチパッドですが、たまに、タッチパッド手前のマウスボタンを使いたい時があり、BIOS で OFF にする以外の方法が無いかネットで調べたところ、gpointing-device-settings というのを入れれば制御出来ることがわかった。しかし、RHEL6 Beta2 には収録されていないようなので、Fedora 12 のものを拾ってきてインストールしました。RHEL6 は Fedora 12 をベースにしているので、たいがいそちらから拾ってくれば動くのでは・・・ System / Preferences / Pointing Devices というメニューが追加されるので、その中の Speed の３つの項目を全てほぼゼロ（１ドットくらい）にすることで、タッチパッドによるマウス移動が最小限に小さくなり、誤操作することがなくなります。しかも、タッチパッド手前のマウスボタンが使えるし、タッチパッドによるスクロール機能も動きます。スクロールの方は、わたしはあまり使いませんが。

・Desktop Effects
Compiz というのがあるは知っていたが、こりゃいい！　マウスポインターを画面右上に持って行くと、ウインドウセレクトできるのだが、このインタフェースがすごくうまく出来ている。Windows のアレよりずっとセンスがいいと思った。仮想デスクトップ切り替え時のサイコロエフェクトも、俯瞰表示もすばらしい。

ThinkPad X301 の導入

自宅開発環境に、新たに ThinkPad X301 を追加導入した。 これまで、X300 上の Windows XP を主に利用していたが、KVM の調査にもう１台欲しいと思っていたところ、lenovo からスペシャルセールのメールが届き、スペック的なことでしばらく迷ったが、結局購入した。モデルは 2777RM5

プリインストールされた Windows 7 Professional もいちおうは残しておきたいため、次のような手順で、パーティション構成を変更し、マルチブート環境を構築した。

1.修復用のDVD x3枚 を作成。
　lenovo のユーティリティにて作成（結構時間かかります）
2.PartedMagic を利用し、Windows 7 領域を 32GB に縮小。
3.そのまま PartedMagic でブートした環境に
　USB-HDD を接続し dd で領域３つをバックアップ。
　C: 以外に Q: および S: (X301ではドライブレターが未割り当て) がある。下記URL参照。
　http://www-06.ibm.com/jp/domino04/pc/support/Sylphd06.nsf/jtechinfo/MIGR-70829
4.パーティション情報もバックアップ。

　# sfdisk -d /dev/sda > /mnt_usb_disk/sfdisk.out
　# fdisk -l /dev/sda > /mnt_usb_disk/fdisk.out

　もしもリストアする場合は、PartedMagic から起動して

　# sfdisk < /mnt_usb_disk/sfdisk.out
　# partprobe

　とやってから、dd で３つの領域にリストアすればいいはず。
5.Q: と S: を削除し、Windows 7 が入った領域を先頭に移動
6.MBM をインストール
　http://elm-chan.org/fsw/mbm/mbm.html 　MBMブータブルCDを使う
7.MBMから Windows 7 が起動できることを確認
8.あとは、Fedora でも CentOS でも空き領域にインストールすればいい
　ただし、GRUB のインストールは、sda の先頭ではなくてパーティションの先頭(sda2 等)

現在の状態は次のような感じ。

# uversion 
Fedora release 13                       2777RM5

BIOS version  : 6EET50WW (3.10 )  03/16/2010
System serial : xxxxxxx

CPU model  : Intel(R) Core(TM)2 Duo CPU     U9400  @ 1.40GHz
Processors : 2  (1 sockets, 2 cores per CPU, HT: not supported or disabled)

Memory : 1839 MB

Linux : 2.6.33.5-124.fc13.x86_64  x86_64  (my41)

# fdisk -l

Disk /dev/sda: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4d1c5e4a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        4207    33792696    7  HPFS/NTFS
/dev/sda2   *        4208        6247    16384000   83  Linux
/dev/sda3            6247        6375     1030144   82  Linux swap / Solaris
/dev/sda4            6376       15566    73826707+   5  Extended
/dev/sda5            6376        8376    16073001   83  Linux
/dev/sda6            8377       10377    16073001   83  Linux
/dev/sda7           10378       12378    16073001   83  Linux
/dev/sda8           12379       14379    16073001   83  Linux
/dev/sda9           14380       15566     9534546   83  Linux
# blkid
/dev/sda1: LABEL="Windows7_OS" UUID="5248CFD848CFB94D" TYPE="ntfs" 
/dev/sda2: UUID="d20e5ed1-4fc8-43e8-877d-9210c3b86bdd" TYPE="ext4" 
/dev/sda3: UUID="4b1ac955-ed75-4684-b2c7-906fcb040552" TYPE="swap" 
/dev/sda7: LABEL="/" UUID="bafc8aaa-8505-41ac-ab9d-25f53969c281" SEC_TYPE="ext2" TYPE="ext3"

インストールしている OS は

sda1 : Windows 7 (プリインストールされていたもの)
sda2 : Fedora 13
sda7 : CentOS 5.5
sda5,6,8,9 : KVM 領域

bashでシンボリック先を得る方法

ls -l の後ろを取得すればいいことはわかるが、もっとましな方法がないのかと調べたところ、readlink というコマンドがあることを知った。ただし、古いディストロには含まれていないので、注意した方がいい。Fedora13 では、coreutils に含まれている。 readlink を多数呼ぶ（したがって多数のプロセスをforkしてしまう）スクリプトを書いているので、できれば bash 自身だけで処理したかったが、そのような機能はなさそう。man bash を link で検索しながら斜め読みしたが、なさげ。 perl で書いてしまうか。

PCIのbus_id設定箇所

故あって、PCIのbus_id設定箇所を調べた。RHEL5 2.6.9-194.el5

int pci_setup_device(struct pci_dev * dev)
{        u32 class;        u8 hdr_type;
...
        sprintf(pci_name(dev), "%04x:%02x:%02x.%d", pci_domain_nr(dev->bus),
                dev->bus->number, PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
"drivers/pci/probe.c"

lspci や ethtool -i eth0 で表示されるPCIカードの位置を示すIDを初期設定する箇所。

ソースコードの行数カウント

bash や awk スクリプトのソースコード行数を計測したかったため、どこかにいいのが無いかなと google で探したが、見当たらず。
＃「コロ助」という Windows 上で動くものはありましたが。

空行とコメント行を考慮できればいい程度なので、awk で書いてみました。

# cat count.gawk 
{
        line++
}
/^[[:blank:]]*$/ {
        space++
}
/^[[:blank:]]*#/ {
        comment++
}
END {
        effect = line - (space + comment)
        printf "%5d  %5d  %5d  %5d  %s\n",
                effect, comment, space, line, FILENAME
}

# gawk -f count.gawk /etc/init.d/kdump
  378     43     49    470  /etc/init.d/kdump

まあ、この程度でも十分。

シェルスクリプトでファイルの更新日時比較

シェルスクリプトでファイルの更新日時(mtime)の比較をやる方法についてメモ。

(方法1) test の -nt と -ot

[root@centos5 ~]# strings /usr/bin/test | grep FILE1
  FILE1 -ef FILE2   FILE1 and FILE2 have the same device and inode numbers
  FILE1 -nt FILE2   FILE1 is newer (modification date) than FILE2
  FILE1 -ot FILE2   FILE1 is older than FILE2

test のヘルプってどうやって出すんだ。。。

(方法2) date -r

[root@centos5 ~]# date -r /etc/grub.conf +"%F %T"
2010-01-24 19:58:18
[root@centos5 ~]# date -r /etc/grub.conf +%s
1264330698

%s seconds since 1970-01-01 00:00:00 UTC
なので、シェル変数に入れていろいろできる。

(方法3) stat -c

[root@centos5 ~]# stat -c "%Y" /etc/grub.conf 
1264250945
[root@centos5 ~]# stat -c "%Y" /boot/grub/grub.conf 
1264330698
[root@centos5 ~]# ls -l /etc/grub.conf 
lrwxrwxrwx 1 root root 22 Jan 23 21:49 /etc/grub.conf -> ../boot/grub/grub.conf
[root@centos5 ~]# ls -l /boot/grub/grub.conf 
-rw------- 1 root root 830 Jan 24 19:58 /boot/grub/grub.conf

これですが、シンボリックリンクの場合は注意する必要があるようです。あと、システムが古いと -c オプションが無いかもしれません。

(方法4) touch -t で一時ファイルを作って、find を使う。

ネットではこの(方法4)が散見されました。