1

I recently recognized some strange behavior of my system and my atime-records of my /home files.

I tried to code a simple script to check whether some files in the /Downloads folder are untouched for some days and delete them afterwards. As I try to code I recognized, that all my files in my /home folder are read in the last two days. I thought this could had something to do with my previous uses of find * in my script.

I tried to reproduce this but the atime did not change.

As I encrypted my personal data I thought this atime-change is the result of decryption on system-startup. I tried to reproduce this with a shutdown and a boot, but the atime did not change.

Now I tried to let my pc alone for a day and don't continue coding to see what will happen. Some minutes ago I started my pc and guess what... All atime-records are set to the boot-up-time. They are not all the same but differ for some seconds.

I tried to get some information with lsof and the "commands" gmain and pool got access to my home-folder. I couldn't figure out what those two "commands" are doing.

Had you ever see those strange behavior and atime-changes on startup? My secound Ubuntu 16.04 pc did not have this changes but personal data in /home-folder are not encrypted on that device.

If you got some idea what causes this atime changes please let me know.

Best regards

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

Update 1

I tried to reproduce this atime-changes with a clean ubuntu 16.04 install in virtualbox with encrypted home-files.

I dont get any atime-changes.

A day later I recognized, that some files got an atime-change immediately as i tried to check the atime with my file-manager. But I could not reproduce this with my clean ubuntu installation in virtualbox.

Any further ideas?

Update 2

OK, I'm really scared now. I check all my /home-files and all of them get accessed on startup. Some atimes are changed directly after startup, some more got accessed after 3 minutes and the big part got accessed after 6 minutes. My XPS 13 boot-process takes less than 1 minute. At the moment I got no idea what is happening.

The only entries in syslog at the time the most files got accessed are:

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

Update 3

After reading through syslog and cronjobs. Maybe this has something to do with google-chome in /etc/chron.daily or org.gnome.zeitgeist.Engine which was started seconds before some files atime was changed.

Update 4

Another day, another information.

Today I get the same atime changes. But theses changes only appears min. 24 hours after the last changes. Furthermore the changes happens exactly after reboot or if I check this changes with ls -ltu in terminal or in nautilus. This is really strange.

I checked syslog again: zeitgeist-daemon crashed seconds after atime was changed :

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'.

But I disabled zeitgeist before boot in system-settings. I already checked activity.sqlite and it was not changed for days. Only the atime of activity.sqlite is changed like all other files. I think this atime-changes had nothing to do with zeitgeist.

Another possibility is ureadahead which was stopped seconds after this 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...

I think some daily cronjob is responsible for this changes. My cron.daily-folder:

-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

Now I will focus on google chrome.

Please let me know if u got some ideas.

Update 5

OK, I think cronjobs are not the problem:

$ 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 )

They run at 06:25 am but the atime changes later.

I compared the cronjobs from cron.daily with the ones from a clean ubuntu installation.

Only send-poke and google-chrome differs. But the time when atimes are changed do not fit.

I removed send-poke, because it's some kind of ping informationes to cannonical from ubuntu-oem-version.

See code here:

apt-get source canonical-poke

Now I have to focus on the time the atime changes. If the change happens yesterday at 4 pm, I can reboot or shutdown and boot my pc until 4 pm today and nothing happens. If I boot after 4 pm the atime changes to boottime. So I think this changes min. after 24 hours.

Update 6

OK, maybe I'm wrong with my thoughts about the 24 hours delay and cronjobs. cat /proc/mounts | grep "/home/" tells me, my home-folder is mounted with relatime, so atime changes are made min. after 24 hours. I think "zeitgeist" is back on the table. I figured out, zeitgeist is not installed on my vanilla-ubuntu-16.04-x64 installation. But on my XPS13 its installed (and disabled) but is started on every boot.

Alex
  • 43

1 Answers1

1

I assume that your home directory is encrypted using ecryptfs. If this in indeed the case, what you are seeing is the expected behavior, although that is not very obvious.

The observed behavior is the result of a combination of two factors:

  1. Whenever you log in, ecryptfs needs to read each encrypted file to get the file encryption key, which is stored in the file header. See man 7 ecryptfs. This should change the last access time of each file to the time you logged in, but ...

  2. By default Ubuntu, as well as most if not all Linux distributions, mounts ext4 filesystems with the option relatime (see man 8 mount), which means that the file access time is updated not on all accesses, but only if it is older than the file change time, or at least 24 hours hours have passed since the last update. This is done to avoid turning every file read into a read followed by a write, thus speeding up operations and protecting storage devices, e.g. SSDs, which are capable of a limited number of writes during their lifetime.

AlexP
  • 10,435