主页 / unix / 问题 / 529827
Accepted
humanityANDpeace
Asked: 2019-07-13 05:39:05 +0800 CST

/var/log/lastlog 是一个巨大的稀疏文件（1.1TB）有什么原因吗？

  • 772

我读过一些问题，询问如何rsync有效地稀疏文件，提到文件/var/log/lastlog和/var/log/faillog. 事实上，我自己也发现这些文件是一个“问题”，因为它们通过 rsync 进行备份会使它们变得“不稀疏”。

因此，我想知道的是，将这些文件设为稀疏、巨大的文件（在我的情况下是 1.1TB）的需求/背景动机是什么？

同样与此相关的是：由于我假设它们是日志文件，所以我不太关心我截断了这些文件，我是否因为截断这些文件而损坏了任何东西？

logs sparse-files

4 个回答

  1. Best Answer

    因此，我想知道的是，将这些文件设为稀疏、巨大的文件（在我的情况下是 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 机器上的字段大小在注释中；一个条目应该是 4 + 32 + 256 = 292 字节。

    每次使用pam_lastlog(8)pam 模块的程序登录用户时，它都会寻找uid * sizeof(struct lastlog)并覆盖与该用户对应的条目。

    我是否因为截断这些文件而损坏了任何东西？

    您确实破坏了lastlog(1)命令的输出，无论如何都没有人使用它;-)

    • 14

  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"*

    “lastlog”在处理具有中间未使用 UID 的条目时将出现挂起

    也许这也可能与观察到的问题有关，因为分配的 FreeIPA LDAP UID 编号比 Linux 中的要大得多

    • 1

  3. 这两个文件是“数据”类型的文件，如果你使用 ls -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”命令检查，实际大小只有几 KB。

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

  4. 通过“截断文件”，而不通知（或重新启动）正在写入日志文件的程序，您导致了稀疏文件。

    最好的解决方法是找到并修复导致所有这些日志消息的问题。

    避免该问题的另一种方法是停止日志记录服务，用于lsof确保没有其他进程打开该文件，然后截断该文件并重新启动日志记录。

    根据要求，这是它（不）如何工作的模型：

    程序打开文件进行“追加”，被告知文件在块 X 处结束，然后写入块 X+1。您“截断文件”，但程序“知道”下一个要写入的块是 X+2。因此，该文件可能会在开始时给出数据，但在块 X+2 处肯定有数据。达达！稀疏文件。

    • -2

相关问题