- - PR -
RHEL4:パーティションサイズを超える巨大なlastlog
1
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2007-10-18 05:25
お世話になっております。Tonbi_koと申します。
初めてスレッドを立てさせていただきました。 表題の件で悩んでおります。 IBMのサーバにx86_64版のRHEL4をインストールし利用しているのですが、/var/log/lastlogのサイズがあろうことか1.2TB(!)を超えています。 lastlogを普通に叩くとごく普通に各UIDの最終ログイン時間が表示されます。 現在サーバが自分の管理下にないので strings等はかけれていません。 lastlogが sparse fileであり、実サイズと見かけのサイズが違う事、sparse fileならパーティションサイズを超えた容量にできる事は重々承知しております。しかし、73GBのディスク(/varの割り当ては40GB程度)に対して1.2TBはちょっと理解でません。 当方、普段はSlackware系Linuxを使っており、そちらのマシンの/var/log/lastlogの見かけサイズはだいたい3MB程度、「lastlogはだいたいこんなもん」という認識でいました。 lastlogのファイルサイズを決めるような設定項目等、いろいろ調べてみましたが見つかりません。pam_lastlog.soやpam_limits.soあたりのライブラリを読み込んでいそうな設定ファイルも探してみましたがなにもないようです。 これで問題なく動いてはいるようなのですが、今後の運用におけるバックアップ/リストアを考えると、はたしてこれで大丈夫なのか?ととても不安です。 実は一度、同じ構成のマシンで/varを溢れさせてしまった時、runlebel1でfsckをかけたところファイルシステムが壊れ起動不可になりました。 この事に関しても、馬鹿げたサイズのlastlogが原因だったのでは?と疑念を抱いております。 同じような現象を体験した方がいましたら、何か解決策のヒントを頂きたいと思います。また、sparse fileを正常に扱うにはどのようなバックアップ方法/コマンドが向いているか等の知識がある方がいましたら、どうかご教授ください。 宜しくお願いします。 | ||||
|
投稿日時: 2007-10-18 14:36
OSのアップデート状態はどうなんでしょうか?
最新ですか? bugzillaでいえば↓のネタっぽいですね。 https://bugzilla.redhat.com/show_bug.cgi?id=192560 なのでnfs-utils関連なのでしょうかね。 コメントの最後の方を読むと。。。 MIRACLE LINUXでも↓に同じ話があります。 http://www.miraclelinux.com/update/linux/ml40sp1.html 削除してからSP1をあてろと言っているので lastlogが大きい状態のままアップデートしても(もしFIXされていたとしても) 小さくならないのかもしれません。 SP1が出たのは結構前ですから最近のRHEL4では現象が 起きていないかもしれません。 バックアップという観点でいえば商用ソフトにはlastlogを 除外するようにマニュアルに書いてあるものもありますし、 rsyncなどは-S(--sparse)オプションなんかが用意されています。 _________________ 桃李不言 下自成蹊 | ||||
|
投稿日時: 2007-10-18 18:47
anightsさま、リプライありがとうございます。
>OSのアップデート状態はどうなんでしょうか? >最新ですか? >bugzillaでいえば↓のネタっぽいですね。 >https://bugzilla.redhat.com/show_bug.cgi?id=192560 2006年8月の議論ですね、こちらは最新になっております。 nfs-utils-1.0.6-80.EL4.src.rpm Tue 10 Apr 2007 03:55:43 AM JST >バックアップという観点でいえば商用ソフトにはlastlogを >除外するようにマニュアルに書いてあるものもありますし、 >rsyncなどは-S(--sparse)オプションなんかが用意されています。 ご回答ありがとうございます。その後CentOSでわざと巨大なsparseファイルをつくり 検証したところ、 tarでのバックアップではsparseファイルをうまく扱えず リカバリ時にディスクのオーバーフローがおきますが、 ddなら大丈夫でした。 しかしやはり、1.25TBというサイズは…。 何かの拍子にディスク障害の原因になる可能性はゼロとはいえませんよね。 引き続き情報があれば、どなたかこれ自体の解消法をご教授願います。 | ||||
|
投稿日時: 2007-10-19 07:54
解決しました。
anights様の投稿にあった、bugzillaの問題がまさにこれでした。 どうやら去年の5月から、x86_64におけるこの問題はbug fixされていないようです。 /etc/passwdを確認したところ、nfsnobodyの UIDが 4294967294になっており (UIDの数値空間は32bitなので、その最大値からマイナス1の数値でしょう) 自分で設定した UID:501のアカウントから nfsnobodyまでの 4294966793個の未登録UIDがlastlogのスパース部分に割り当てられていたようです。 該当アカウントを削除して、/dev/nullを /var/lastlogに流し込み、再ログインしたところ lastlogの見かけファイルサイズは数百バイトに激減しました。 「sparse fileの罠」はよく言われますが、恐ろしいですね。 もし UIDの数値空間が64bitだったらこのままファイルシステムが壊れていますよね。 | ||||
|
投稿日時: 2007-10-19 16:44
訂正。 bugzilla的には↓ですね。 https://bugzilla.redhat.com/show_bug.cgi?id=149407 私が載せたのはFedoraだったようですね。 なのでFIXはされているようですよ。 nfsnobodyでログインしなければでっかくならないという意味ですが。 流れとしては nfs-utilsをインストールする際にnfsnobodyを作成するのですが(useraddで) その際、lastlogをUID分広げます。 だから1.2Tぐらいになったつーことですね。 現在の、nfs-utilsパッケージではuseraddに-lオプションを付けて実行しています。 shadow-utilsに含まれているuseraddにも変更があって-lオプションを付けることで lastlogを触らなくなっています。 # LANG=C man useradd ※日本語のmanは更新が追いついていません に情報があります。 ただnfsnobodyでログインすればでっかくなりますけどね。 まあデフォルトのshellはnologinだし、pamとかでも引っかかるから 意図的にログインしないと出来ませんし、これは仕様っていえるんじゃないかねぇ。 lastlogってそういうものだし。 _________________ 桃李不言 下自成蹊 |
1