☰

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

tag-icon • tag-icon logs sparse-files
/var/log/lastlog 是一个巨大的稀疏文件（1.1TB）是否有原因？

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

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

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

我是否因截断这些文件而损坏了任何内容？

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

答案2

在我们引入一些（大型）LDAP UID 号与 Linux (RHEL 7) 计算机中的“正常”UNIX 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 中的 UID 编号大得多

答案3

这两个文件是“数据”类型文件。如果你检查 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磁盘块为单位），则实际大小只有几KB。

[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 处有数据。哒哒！稀疏文件。

相关内容