☰

/var/log/lastlogが巨大な希少ファイル（1.1TB）である理由はありますか？

tag-icon • tag-icon logs sparse-files
/var/log/lastlogが巨大な希少ファイル（1.1TB）である理由はありますか？

私はファイルを効率的にスパイする方法を尋ねるいくつかの質問を読んでrsync、ファイル/var/log/lastlogと/var/log/faillog。

それで、私が気になったのは、これらのファイルをまれに大きなファイル（私の場合は1.1TB）として持つ必要性/背景の動機ですか？

これに関連するフォローアップ：ログファイルであると仮定しているため、このファイルを切り捨てることにはあまり興味がありません。このファイルを切り取って破損したものはありますか？

答え1

それで、私が気になったのは、これらのファイルをまれに大きなファイル（私の場合は1.1TB）として持つ必要性/背景の動機ですか？

状況はこうなります。

/var/log/lastlogそのようなログファイルの代わりに、/var/log/syslog名前は「最後のログファイル」ではなく「最後のログインリスト」でなければなりません。

これはpam_lastlog(8)モジュールによって維持され、基本的には次のような配列です。

struct lastlog {
    time_t  ll_time;    // 4
    char    ll_line[UT_LINESIZE];   // 32
    char    ll_host[UT_HOSTSIZE];   // 256
} entry[UINT_MAX];

一般的なx86-64システムのフィールドサイズは注釈に記載されています。 1つの項目は4 + 32 + 256 = 292バイトでなければなりません。

pamモジュールを使用するプログラムは、pam_lastlog(8)ユーザーにログインするたびにそのuid * sizeof(struct lastlog)ユーザーに対応するエントリを見つけて上書きします。

このファイルを切り取って破損した部分がありますか？

あなたは実際にコマンドの出力を破損しており、lastlog(1)とにかく誰もそれを使用しません;-)

答え2

Linux（RHEL 7）システムでは、「一般」UNIX UID番号と共存するために、いくつかの（大きな）LDAP UID番号を導入した後にこの動作を確認しました。

また、「lastlog」のマニュアルページの「CAVEATS」セクションには次のように記載されています。

  *"Large gaps in UID numbers will cause the lastlog program to run longer with no output to the screen"*

途中で未使用のUIDを持つアイテムを処理すると、「lastlog」がハングしたようです。

割り当てられたFreeIPA LDAP UID番号はLinuxのUID番号よりはるかに大きいため、これは観察された問題にも関連する可能性があります。

答え3

これら2つのファイルは「データ」タイプファイルです。 usingls -lまたはls -lhコマンドをチェックすると、非常に大量のディスク容量を占めることがわかりますが、実際にはそうではありません。

ls -sそのファイルの実際のサイズを確認するコマンドです。

[root@LinuxServer ~]# file /var/log/lastlog /var/log/faillog
/var/log/lastlog: data
/var/log/faillog: data
[root@LinuxServer ~]# ls -l /var/log/lastlog /var/log/faillog
-rw------- 1 root osg       3166464 Jul  8 21:20 /var/log/faillog
-rw-r--r-- 1 root root 304854077980 Jul 14 21:38 /var/log/lastlog
[root@LinuxServer ~]# ls -lh /var/log/lastlog /var/log/faillog
-rw------- 1 root osg  3.1M Jul  8 21:20 /var/log/faillog
-rw-r--r-- 1 root root 284G Jul 14 21:38 /var/log/lastlog
[root@LinuxServer ~]#

ls -sコマンドで確認すると（出力は-sディスクブロック単位です）、実際のサイズはわずか数キロバイトです。

[root@LinuxServer ~]# ls -s /var/log/lastlog /var/log/faillog
3100 /var/log/faillog   748 /var/log/lastlog

答え4

ログファイルに書き込んでいるプログラムに通知したり、再起動せずに「ファイルを切り捨てる」と、スパースファイルが生成されます。

最善の解決策は、これらすべてのログメッセージを引き起こす問題を見つけて解決することです。

問題を回避する別の方法は、ロギングサービスを停止し、lsof他のプロセスでファイルが開いていないことを確認してから、ファイルを切り捨ててロギングを再開することです。

要求に応じて、どのように動作するかについてのモデルは次のとおりです。

プログラムは「追加」のためにファイルを開き、ファイルがブロックXで終わるというメッセージを聞き、ブロックX + 1を書き込みます。ユーザーは「ファイルを切り捨てますが」プログラムは、書き込む次のブロックがX + 2であることを「知っています」。したがって、ファイルは最初はデータを提供できますが、X + 2ブロックには明らかにデータがあります。ダダ！スパースファイル。

関連情報