主文件夹中的 atime 发生奇怪变化

主文件夹中的 atime 发生奇怪变化

我最近发现我的系统和 /home 文件的 atime 记录存在一些奇怪的行为。

我尝试编写一个简单的脚本来检查 /Downloads 文件夹中的某些文件是否在几天内未被触及,然后将其删除。当我尝试编写代码时,我意识到我的 /home 文件夹中的所有文件都是在过去两天内读取的。我认为这可能与我之前find *在脚本中的使用有关。

我尝试重现此现象但 atime 并未改变。

由于我加密了我的个人数据,我认为这个 atime 变化是系统启动时解密的结果。我尝试通过关机和启动来重现这种情况,但 atime 并没有改变。

现在我尝试让我的电脑静置一天,不继续编码,看看会发生什么。几分钟前我启动了我的电脑,你猜怎么着……所有 atime 记录都设置为启动时间。它们并不完全相同,但会相差几秒钟。

我尝试使用 lsof 和“命令”获取一些信息gmain,并pool访问了我的主文件夹。我不明白这两个“命令”在做什么。

您是否曾在启动时看到过这些奇怪的行为和时间变化?我的第二台 Ubuntu 16.04 电脑没有这些变化,但 /home 文件夹中的个人数据在该设备上未加密。

如果您知道是什么原因导致了这个时间变化,请告诉我。

此致

亚历克斯

Linux debby 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux


Ubuntu 16.04.1 LTS \n \l

更新 1

我尝试使用在 virtualbox 中安装的全新 ubuntu 16.04 并加密主文件来重现此 atime-changes。

我没有收到任何时间变化。

一天后,当我尝试使用文件管理器检查访问时间时,我发现某些文件立即发生了访问时间更改。但我无法使用 VirtualBox 中全新安装的 Ubuntu 重现此问题。

还有其他想法吗?


更新 2

好吧,我现在真的很害怕。我检查了我所有的 /home 文件,发现它们都在启动时被访问。有些 atime 在启动后直接更改,有些在 3 分钟后被访问,大部分在 6 分钟后被访问。我的 XPS 13 启动过程不到 1 分钟。目前我不知道发生了什么。

大多数文件被访问时系统日志中的唯一条目是:

Nov 26 16:32:50 *** gnome-session[1869]: (nm-applet:2026): GLib-CRITICAL **: g_hash_table_remove_all: assertion 'hash_table != NULL' failed
Nov 26 16:32:50 *** gnome-session[1869]: (nm-applet:2026): nm-applet-CRITICAL **: nma_icons_free: assertion 'NM_IS_APPLET (applet)' failed

更新 3

在阅读了 syslog 和 cronjobs 之后,这可能与 /etc/chron.daily 或 org.gnome.zeitgeist.Engine 中的 google-chome 有关,它们在某些文件的 atime 更改前几秒启动。


更新 4

另一天,另一条信息。

今天我得到了相同的 atime 更改。但这些更改仅在上次更改后至少 24 小时才出现。此外,更改恰好在重启后发生,或者如果我在ls -ltu终端或 nautilus 中检查这些更改,更改就会发生。这真的很奇怪。

我再次检查了系统日志:zeitgeist-daemon 在 atime 更改几秒后崩溃了:

Nov 27 16:52:45 *** org.gnome.zeitgeist.Engine[1680]: (zeitgeist-daemon:2898): GLib-GIO-WARNING **: Error releasing name org.gnome.zeitgeist.Engine: The connection is closed
Nov 27 16:52:45 *** org.gnome.zeitgeist.Engine[1680]: #033[31m[15:52:45.020982 WARNING]#033[0m zeitgeist-daemon.vala:449: The connection is closed
Nov 27 16:54:11 *** gnome-session[1895]: ** (zeitgeist-datahub:2496): WARNING **: zeitgeist-datahub.vala:229: Unable to get name "org.gnome.zeitgeist.datahub" on the bus!
Nov 27 16:54:11 *** org.gnome.zeitgeist.Engine[1748]: ** (zeitgeist-datahub:2516): WARNING **: kde-recent-document-provider.vala:174: Couldn't find actor for 'basket'.

但我在系统设置中启动前禁用了 zeitgeist。我已经检查了 activity.sqlite,它几天都没有改变。只有 activity.sqlite 的 atime 像所有其他文件一样发生了变化。我认为这个 atime 变化与 zeitgeist 无关。

另一种可能性是 ureadahead 在这次 atime-changes 之后几秒就停止了:

Nov 27 16:54:28 *** systemd[1]: Starting Stop ureadahead data collection...
Nov 27 16:54:28 *** systemd[1]: Stopped Read required files in advance.
Nov 27 16:54:28 *** systemd[1]: Started Stop ureadahead data collection.
Nov 27 16:55:40 *** systemd[1]: Stopping User Manager for UID 109...

我认为某些日常 cronjob 导致了这些变化。我的 cron.daily 文件夹:

-rwxr-xr-x 1 root root 1474 Nov 26 17:42 apt-compat
-rwxr-xr-x 1 root root 3449 Nov 26 17:42 popularity-contest
-rwxr-xr-x 1 root root 2263 Nov 26 17:42 send-poke
-rwxr-xr-x 1 root root  214 Nov 26 17:42 update-notifier-common
-rwxr-xr-x 1 root root  311 Nov 26 17:42 0anacron
-rwxr-xr-x 1 root root  376 Nov 26 17:42 apport
-rwxr-xr-x 1 root root  355 Nov 26 17:42 bsdmainutils
-rwxr-xr-x 1 root root  384 Nov 26 17:42 cracklib-runtime
-rwxr-xr-x 1 root root 1597 Nov 26 17:42 dpkg
-rwxr-xr-x 1 root root  372 Nov 26 17:42 logrotate
-rwxr-xr-x 1 root root 1293 Nov 26 17:42 man-db
-rwxr-xr-x 1 root root  435 Nov 26 17:42 mlocate
-rwxr-xr-x 1 root root  249 Nov 26 16:30 passwd
-rwxr-xr-x 1 root root 1046 Nov 26 16:30 upstart
lrwxrwxrwx 1 root root   37 Nov 26 16:25 google-chrome -> /opt/google/chrome/cron/google-chrome

现在我将重点介绍 Google Chrome。

如果您有任何想法,请告诉我。


更新 5

好的,我认为 cronjobs 不是问题:

$ grep run-parts /etc/crontab
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

它们于上午 06:25 运行,但时间会更改得较晚。

我将 cron.daily 中的 cronjobs 与干净的 ubuntu 安装中的 cronjobs 进行了比较。

只有 send-poke 和 google-chrome 不同。但是 atimes 更改的时间不对。

我删除了 send-poke,因为它是来自 ubuntu-oem-version 的某种 ping 信息。

请参阅此处的代码:

apt-get source canonical-poke

现在我必须关注 atime 更改的时间。如果更改发生在昨天下午 4 点,我可以重新启动或关闭并启动我的电脑,直到今天下午 4 点,什么也不会发生。如果我在下午 4 点之后启动,atime 会更改为 boottime。所以我认为这会在 24 小时后发生变化。


更新 6

好吧,也许我对 24 小时延迟和 cronjobs 的想法是错误的。cat /proc/mounts | grep "/home/"告诉我,我的主文件夹是用 relatime 安装的,所以 atime 更改至少在 24 小时后进行。我想“zeitgeist”又回到了桌面上。我发现,zeitgeist 没有安装在我的 vanilla-ubuntu-16.04-x64 安装上。但在我的 XPS13 上它已安装(并已禁用),但每次启动时都会启动。

答案1

我假设你的主目录使用 ecryptfs 加密。如果确实如此,你看到的是预期行为,尽管这不是很明显。

观察到的行为是两个因素结合的结果:

  1. 每当您登录时,ecryptfs 都需要读取每个加密文件以获取文件加密密钥,该密钥存储在文件头中。请参阅man 7 ecryptfs。这应该会将每个文件的最后访问时间更改为您登录的时间,但是...

  2. 默认情况下,Ubuntu 以及大多数(如果不是全部)Linux 发行版都使用选项relatime(请参阅man 8 mount)安装 ext4 文件系统,这意味着文件访问时间并非在所有访问时都更新,而只有当它早于文件更改时间或自上次更新以来至少已过去 24 小时时才会更新。这样做是为了避免将每个文件读取变成读取后写入,从而加快操作速度并保护存储设备(例如 SSD),这些设备在其生命周期内只能进行有限次数的写入。

相关内容