Странный atime изменяется в папке дома

Я недавно распознал некоторое странное поведение своей системы и своих atime-записей моего / домашние файлы.

Я пытался кодировать простой сценарий, чтобы проверить, являются ли некоторые файлы в папке Downloads / нетронутыми в течение нескольких дней и удаляют их впоследствии. Поскольку я пытаюсь кодировать, я распознал, что все мои файлы в моем / домашняя папка читаются за прошлые два дня. Я думал, что это могло, имел некоторое отношение к моему предыдущему использованию find * в моем сценарии.

Я пытался воспроизвести это, но atime не изменился.

Когда я зашифровал свои персональные данные, я думал, что это atime-изменение является результатом дешифрования на системном запуске. Я пытался воспроизвести это с завершением работы и начальной загрузкой, но atime не изменился.

Теперь я пытался позволить одному только своему ПК в течение дня и не продолжаю кодировать для наблюдения то, что произойдет. Несколько минут назад я запустил свой ПК, и угадайте что... Все atime-записи установлены на время начальной загрузки. Они не являются всеми одинаковыми, но отличаются в течение нескольких секунд.

Я пытался получить некоторую информацию с lsof и "командами" gmain и pool получил доступ к моей папке дома. Я не мог выяснить то, что делают те две "команды".

Вы имели, когда-нибудь смотрите их странное поведение и atime-изменения на запуске? Мой второй ПК Ubuntu 16.04 не имел, это изменяется, но персональные данные в/home-folder не шифруются на том устройстве.

Если Вы получили некоторое представление, что вызывает этот atime изменения, сообщенные мне.

С уважением

Alex

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

Я пытался воспроизвести, это atime-изменяется с чистой установкой человечности 16.04 в virtualbox с зашифрованными файлами дома.

Я не получаю atime-изменений.

День спустя я распознал, что некоторые файлы сразу получили atime-изменение, когда я пытался проверить atime со своим файловым менеджером. Но я не мог воспроизвести это со своей чистой установкой человечности в virtualbox.

Дальнейшие идеи?

---

Обновление 2

Хорошо, я действительно боюсь теперь. Я проверяю все мой/home-files, и ко всем ним получают доступ на запуске. Некоторые atimes изменяются непосредственно после запуска еще немного к получили доступ после того, как к 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

После прочтения системного журнала и cronjobs. Возможно, это имеет некоторое отношение к google-chome в/etc/chron.daily или org.gnome.zeitgeist. Механизм, который был запущенными секундами перед некоторыми файлами atime, был изменен.

---

Обновление 4

Другой день, другая информация.

Сегодня я получаю те же изменения atime. Но тезисы изменяются, только появляется минута спустя 24 часа после последних изменений. Кроме того, изменения происходят точно после перезагрузки или если я проверяю, что это изменяется с ls -ltu в терминале или в наутилусе. Это действительно странно.

Я проверил системный журнал снова: демон духа времени отказал спустя секунды после того, как 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'.

Но я отключил дух времени перед начальной загрузкой в параметрах настройки системы. Я уже проверил activity.sqlite, и он не был изменен в течение многих дней. Только atime activity.sqlite изменяется как все другие файлы. Я думаю, что это atime-изменяет дух времени, к которому не имеют никакого отношения.

Другая возможность является ureadahead, который был остановленными секундами после того, как это atime-изменяется:

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 )

Они работают в 6:25, но atime изменяется позже.

Я сравнил cronjobs от cron.daily с теми от чистой установки человечности.

Только отправьте - вводят по абсолютному адресу, и Google Chrome отличается. Но время, когда atimes изменяются, не соответствует.

Я удалил, отправляют - вводят по абсолютному адресу, потому что это - некоторая информация о ping к каноническому от ubuntu-oem-version.

См. код здесь:

apt-get source canonical-poke

Теперь я должен сфокусировать на времени изменения atime. Если изменение происходит вчера в 16:00, я могу перезагрузить или завершить работу и загрузить свой ПК до 16:00 сегодня, и ничего не происходит. Если я загружаю после 16:00 изменения atime во времени начальной загрузки. Таким образом, я думаю, что это изменяет минуту после 24 часов.

---

Обновление 6

Хорошо, возможно, я неправ со своими мыслями о задержке и cronjobs этих 24 часов. cat /proc/mounts | grep "/home/" говорит мне, моя папка дома смонтирована с в реальном времени, таким образом, изменения atime внесены минута после 24 часов. Я думаю, что "дух времени" вернулся на таблице. Я выяснил, дух времени не установлен на моей vanilla-ubuntu-16.04-x64 установке. Но на моем XPS13 ее установленный (и отключенный), но запускается на каждой начальной загрузке.