/tmp領域が急激に消費されるが、ファイルは存在しない現象について

[長谷川 祐介]

長谷川と言います。宜しくお願いします。

/tmp領域が急激に消費されるが（dfで確認）、
ファイルは存在しない（duで確認）という現象が度々発生しています。

[root@host ~]# df -h /tmp
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/systemvg-tmplv
1008M 957M 0 100% /tmp

[root@host ~]# du -hs /tmp
200K /tmp

以下のページにある現象が該当するのではと考えていますが、
どのプロセスがどの（消えてしまった）ファイルを握っているのか
判別する手段に悩んでいます。

Linux とWindows では「ファイルを消す」際の挙動が異なるんだ。気をつけろ - Slow Dance
http://d.hatena.ne.jp/LukeSilvia/20081001/p1

bind, apache, postfix, spamassasin, dovecot, mysql は再起動を試しましたが、変化はありません。
システムの再起動は試していません。

プロセスが握っているファイルと、そのプロセスを特定する方法はありませんでしょうか？
もしくは、/tmp領域が急激に消費される原因について、別の理由はありませんでしょうか？

CentOS release 5.2 (Final)
bind-9.3.4-6.0.2.P1.el5_2
dovecot-1.0.7-2.el5
httpd-2.2.3-11.el5_1.centos.3
mailman-2.1.9-4.el5
mysql-server-5.0.45-7.el5
postfix-2.3.3-2
spamassassin-3.2.4-1.el5.rf

以上、宜しくお願い致します。

[dezawa]

dezawaです
「Linux とWindows では「ファイルを消す」際の挙動が異なるんだ。気をつけろ」
のページの下のほうに出ているではありませんか、 lsof です。

ls ではでてこなくても、lsof ならプロセスがつかんでいる間表示されます。
lsof|grep tmp
で /tmp のファイルを調べ、その中でサイズが大きくて、ls では出てこないものが
それです。

[長谷川 祐介]

dezawaさん

返信ありがとうございます。

ご指摘のあった
# lsof | grep tmp
と共に、該当ページに記載のあった
# ls -l /proc/*/fd | grep tmp
でも検索してみましたが、せいぜい7KB程度のファイルしかありませんでした。

Linux とWindows では「ファイルを消す」際の挙動が異なるんだ。気をつけろ - Slow Dance
http://d.hatena.ne.jp/LukeSilvia/20081001/p1

にある現象が原因ではないと考えるのが妥当でしょうか？

[dezawa]

出沢です

はて、、、、
それ以外の原因はちょっと思いつかない。
もしリブートできるならしてみてください。
それで空きが増えていたら原因はそれ、変わらなかったら原因は他、となるかな。

[y.hoshino]

星野と申します。
Linux初心者ですので、見当違いかもしれませんが・・・

試してみたところ、渡しもdfとduとで/tmpの容量が違います。
ただ、/　と　/tmp　のマウント位置が同じパーティションになっていまして、
df　→　マウント先全体の容量
du　→　/tmpフォルダの容量
が表示されているようです。

[L.Takashi ISHIOKA]

>> On Wed, 21 Jan 2009 23:22:36 +0900, 長谷川 祐介 <linux...@hyk-home.com> said:

長谷川> dezawaさん
長谷川> 返信ありがとうございます。

長谷川> ご指摘のあった
長谷川> # lsof | grep tmp
長谷川> と共に、該当ページに記載のあった
長谷川> # ls -l /proc/*/fd | grep tmp
長谷川> でも検索してみましたが、せいぜい7KB程度のファイルしかありませんでした。

fuser -v -m /tmp あたりで, /tmp にアクセスしているプロセスを
みてみると何か手がかりは無いですか?

#これも 同じ所を見て出してると思うので 先の方法でダメだと
#ダメな気もします.

# 「ファイルシステムに不具合(fsck でなおる)」とか, 「意図的に見えない
# ようにされている(悪意のあるプログラムで)」 くらいしか後は思いつかない.
--
(ishi)

[dezawa]

出沢です

> 試してみたところ、渡しもdfとduとで/tmpの容量が違います。
> ただ、/　と　/tmp　のマウント位置が同じパーティションになっていまして、
> df　→　マウント先全体の容量
> du　→　/tmpフォルダの容量

これは長谷川さんの場合はないです。
lsof |grep tmp で出て来ないと言うので、私もそれを考えたのですが

> > [root@host ~]# df -h /tmp
> > Filesystem サイズ 使用 残り 使用% マウント位置
> > /dev/mapper/systemvg-tmplv
> > 1008M 957M 0 100% /tmp

という事ですから、/tmp は独立パーティションです

[長谷川 祐介]

ishi さん

> fuser -v -m /tmp あたりで, /tmp にアクセスしているプロセスを
> みてみると何か手がかりは無いですか?

コマンドを実行し、表示されたプロセスを再起動してみましたが、dfの表示結果に変化はありませんでした。

> # 「ファイルシステムに不具合(fsck でなおる)」

fsckを試してみました。
inodeが関連づけられていないいくつかのファイルが開放されたようですが、
ファイルサイズは小さいモノでした。

出沢 さん

> もしリブートできるならしてみてください。
> それで空きが増えていたら原因はそれ、変わらなかったら原因は他、となるかな。

リブートを試してみましたが、結果は変化無しでした。

リブートついでに、KNOPPIX 5.3.1日本語版で起動し、マウントして確かめてみましたが、
df・duの表示結果に変わりはありませんでした。
そのため、ishi さんがご指摘されていた

> # 「意図的に見えないようにされている(悪意のあるプログラムで)」

の可能性は低いと考えます。

何か他に理由は…あるのでしょうか？

[dezawa]

出沢です

なんだか判らないけれど、とにかく復旧したい -> /tmp を mkfsしなおす
また起きるかもしれないし、原因を掴みたい -> さてどうしたものか

dfからみて inodeは全部使われている
duからみて dirからたどれない使用済inodeがある
fsckでもそれはひっかからない。

df、du、fsck はどこから情報取るんでしたっけ
df inode du dirからたどるinode かな。
ソ-ス読まないと、どうして不可視なのか判らん。
が、読む元気ないなぁ。。

[西田秀雄]

西田と申します。

解決策ではありませんが、UbuntuやKnoppixなどのCD/DVDブートできるOSでマウ
ントしてみるか、そのHDDを別なPCに接続して容量など確認してみてはいかがで
しょうか。

------------------------------------------------------------
Nish - Hideo Nishita - / nis...@jomon.ne.jp

[Kawasaki Tatsuo]

こんにちは、川崎と申します。

2009/1/22 長谷川 祐介 <linux...@hyk-home.com>:

ホントに不思議ですね。

dumpe2fs /dev/mapper/systemvg-tmplv で
スーパーブロックの情報あたりにヒントがないでしょうか？

あるいは、/tmp ディレクトリで du -s * すると
何か怪しい結果になったりしません・・か？

--
Tatsuo Kawasaki
kawasaki at wwing.net
kawamon at gmail.com (web mail)

[長谷川 祐介]

◆出沢さん

> なんだか判らないけれど、とにかく復旧したい -> /tmp を mkfsしなおす
> また起きるかもしれないし、原因を掴みたい -> さてどうしたものか

とりあえずはtmp LVを5GB程度に拡張して様子を見ようと思います。
# LVMにしといて良かった！
しかし、これまで数回発生している事象なので、原因が判明できればと思っています。

◆西田さん

> 解決策ではありませんが、UbuntuやKnoppixなどのCD/DVDブートできるOSでマウ
> ントしてみるか、そのHDDを別なPCに接続して容量など確認してみてはいかがで
> しょうか。

KNOPPIX 5.3.1日本語版で試してみましたが、表示に変化ありませんでした。

◆川崎さん
> dumpe2fs /dev/mapper/systemvg-tmplv で
> スーパーブロックの情報あたりにヒントがないでしょうか？

・dumpe2fsの表示結果は、使用：約49MB、空き：約974MBでした。
これはdf, duどちらの結果にも一致しない結果に見えます。

・言い忘れてしまってましたが、突然/tmp領域が消費された後、
使用領域は時間と共に「徐々に」開放されていきます（dfの表示上）。
現在は発生から1週間ほどですが、34MBが開放されたようです。

[root@host ~]# df -h

Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/systemvg-tmplv

1008M 34M 924M 4% /tmp

[root@host ~]# du -hs /tmp

184K /tmp

[root@host ~]# dumpe2fs /dev/mapper/systemvg-tmplv
dumpe2fs 1.39 (29-May-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 47928af8-4a26-4858-bf76-ac9625b4a434
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 131072
Block count: 262144
Reserved block count: 13107
Free blocks: 249458
Free inodes: 131002
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 63
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Wed Jan 3 01:32:22 2007
Last mount time: Thu Jan 22 22:50:17 2009
Last write time: Thu Jan 22 22:50:17 2009
Mount count: 1
Maximum mount count: -1
Last checked: Thu Jan 22 22:50:16 2009
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
First orphan inode: 23
Default directory hash: tea
Directory Hash Seed: f8244715-7eb4-4574-ac28-4cbdd18d2276
Journal backup: inode blocks
Journal size: 32M

Group 0: (Blocks 0-32767)
Primary superblock at 0, Group descriptors at 1-1
Reserved GDT blocks at 2-64
Block bitmap at 65 (+65), Inode bitmap at 66 (+66)
Inode table at 67-578 (+67)
23921 free blocks, 16338 free inodes, 2 directories
Free blocks: 581-583, 8793-8795, 8798-8799, 8801-8811, 8835-10240, 10244-11280, 11282-12287, 12289, 12291-19510, 19512-22539, 22542-24583, 24585, 24592-24593, 24595-26623, 26629-26631, 26633-28673, 28675-30734, 30736-30738, 30745-32767
Free inodes: 34, 41-43, 50, 52-16384
Group 1: (Blocks 32768-65535)
Backup superblock at 32768, Group descriptors at 32769-32769
Reserved GDT blocks at 32770-32832
Block bitmap at 32833 (+65), Inode bitmap at 32834 (+66)
Inode table at 32835-33346 (+67)
32184 free blocks, 16379 free inodes, 5 directories
Free blocks: 33347-38911, 38913-40959, 40961-43007, 43009-45055, 45057-59391, 59393-65535
Free inodes: 16388-16389, 16392-32768
Group 2: (Blocks 65536-98303)
Block bitmap at 65536 (+0), Inode bitmap at 65537 (+1)
Inode table at 65538-66049 (+2)
32248 free blocks, 16378 free inodes, 6 directories
Free blocks: 66050-67583, 67586-94207, 94211-96255, 96257-98303
Free inodes: 32775-49152
Group 3: (Blocks 98304-131071)
Backup superblock at 98304, Group descriptors at 98305-98305
Reserved GDT blocks at 98306-98368
Block bitmap at 98369 (+65), Inode bitmap at 98370 (+66)
Inode table at 98371-98882 (+67)
32183 free blocks, 16378 free inodes, 6 directories
Free blocks: 98883-112639, 112641-114687, 114689-120831, 120833, 120835-122879, 122881-126975, 126977-131071
Free inodes: 49159-65536
Group 4: (Blocks 131072-163839)
Block bitmap at 131072 (+0), Inode bitmap at 131073 (+1)
Inode table at 131074-131585 (+2)
32246 free blocks, 16376 free inodes, 8 directories
Free blocks: 131586-133119, 133122-135167, 135169-147455, 147457-153599, 153601-161791, 161795-163839
Free inodes: 65542-65603, 65606-65646, 65648-81920
Group 5: (Blocks 163840-196607)
Backup superblock at 163840, Group descriptors at 163841-163841
Reserved GDT blocks at 163842-163904
Block bitmap at 163905 (+65), Inode bitmap at 163906 (+66)
Inode table at 163907-164418 (+67)
32184 free blocks, 16379 free inodes, 5 directories
Free blocks: 164419-165887, 165889-174079, 174081-176127, 176129-182271, 182273-192511, 192513-196607
Free inodes: 81926-98304
Group 6: (Blocks 196608-229375)
Block bitmap at 196608 (+0), Inode bitmap at 196609 (+1)
Inode table at 196610-197121 (+2)
32249 free blocks, 16379 free inodes, 5 directories
Free blocks: 197122-202751, 202753-208895, 208897-212991, 212993-219135, 219138-229375
Free inodes: 98310-114688
Group 7: (Blocks 229376-262143)
Backup superblock at 229376, Group descriptors at 229377-229377
Reserved GDT blocks at 229378-229440
Block bitmap at 229441 (+65), Inode bitmap at 229442 (+66)
Inode table at 229443-229954 (+67)
32183 free blocks, 16378 free inodes, 6 directories
Free blocks: 229956-233471, 233473-233547, 233549-233552, 233554-235519, 235521-243711, 243713-262143
Free inodes: 114693-114741, 114743-114744, 114746-131072

[Kawasaki Tatsuo]

長谷川さん

こんばんは、川崎です。dumpe2fsありがとうございます。

dumpe2fsの結果を見ると、確かに空いていらっしゃるようです。

> Inode count: 131072
> Block count: 262144

> Free blocks: 249458
> Free inodes: 131002

> 現在は発生から1週間ほどですが、34MBが開放されたようです。
今は 34MB の使用状態にまで徐々に空いてきて、ほとんどが
ようやく空きに戻ったという感じなんでしょうか？

> [root@host ~]# df -h
> Filesystem サイズ 使用 残り 使用% マウント位置
> /dev/mapper/systemvg-tmplv
> 1008M 34M 924M 4% /tmp

しかし再現性があるんですね。。厄介そうですが、論理ボリュームの
サイズを大きくすることで改善されたら良いですね。
(根本的な解決になるかはわかりませんが・・）

＃ディスク使用量がFullに近かったときのdumpe2fsの結果が見たいなぁ、と
＃ちょっと思ったんですけど、忘れてください :)
--
kawasaki at wwing.net

2009/1/23 長谷川 祐介 <linux...@hyk-home.com>:

<snip>