Mudanças estranhas no arquivo home-folder

1

Recentemente, reconheci um comportamento estranho do meu sistema e meus registros atime dos meus arquivos / home.

Eu tentei codificar um script simples para verificar se alguns arquivos na pasta / Downloads estão intocados por alguns dias e excluí-los depois. Enquanto tento codificar, reconheci que todos os meus arquivos em minha pasta / home foram lidos nos últimos dois dias. Eu pensei que isso poderia ter algo a ver com meus usos anteriores de find * no meu script.

Eu tentei reproduzir isso, mas o atime não mudou.

Como criptografei meus dados pessoais, achei que essa alteração de tempo é o resultado da descriptografia na inicialização do sistema. Tentei reproduzir isso com um desligamento e uma inicialização, mas o atime não mudou.

Agora eu tentei deixar meu pc sozinho por um dia e não continuei codificando para ver o que vai acontecer. Há alguns minutos eu iniciei meu pc e adivinhe ... Todos os atime-records estão configurados para o tempo de inicialização. Eles não são todos iguais, mas diferem por alguns segundos.

Eu tentei obter algumas informações com o lsof e os "comandos" gmain e pool acessaram a minha pasta pessoal. Não consegui descobrir o que esses dois "comandos" estão fazendo.

Você já viu esse comportamento estranho e alterações de atime na inicialização? Meu secound Ubuntu 16.04 pc não tinha essas mudanças, mas os dados pessoais em / home-folder não são criptografados naquele dispositivo.

Se você tem alguma ideia do que causa essas mudanças, por favor me avise.

Atenciosamente

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

Atualização 1

Eu tentei reproduzir este atime-changes com uma instalação limpa do ubuntu 16.04 no VirtualBox com arquivos caseiros criptografados.

Eu não recebo nenhuma mudança de horário.

Um dia depois, reconheci que alguns arquivos recebiam uma mudança imediata assim que eu tentava verificar o tempo com meu gerenciador de arquivos. Mas eu não consegui reproduzir isso com a minha instalação limpa no ubuntu virtualbox.

Alguma outra ideia?

Atualização 2

OK, estou com muito medo agora. Eu verifico todos os meus arquivos / home e todos eles são acessados na inicialização. Alguns atimes são alterados diretamente após a inicialização, mais alguns acessados após 3 minutos e a grande parte acessada após 6 minutos. Meu processo de inicialização do XPS 13 leva menos de 1 minuto. No momento, não tenho ideia do que está acontecendo.

As únicas entradas no syslog no momento em que a maioria dos arquivos foram acessadas são:

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

Atualização 3

Depois de ler o syslog e os cronjobs. Talvez isso tenha algo a ver com o google-chome em /etc/chron.daily ou org.gnome.zeitgeist.Engine que foi iniciado segundos antes de alguns arquivos serem alterados.

Atualização 4

Outro dia, outra informação.

Hoje recebo as mesmas alterações de horário. Mas essas alterações só aparecem min. 24 horas após as últimas alterações. Além disso, as mudanças acontecem exatamente após a reinicialização ou se eu verificar essas alterações com ls -ltu no terminal ou no nautilus. Isso é realmente estranho.

Eu verifiquei o syslog novamente: O zeitgeist-daemon caiu segundos após o atime ser alterado:

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

Mas desativei o zeitgeist antes de inicializar nas configurações do sistema. Eu já verifiquei o activity.sqlite e ele não foi alterado por dias. Apenas o atime de activity.sqlite é alterado como todos os outros arquivos. Eu acho que essas mudanças de atime não tinham nada a ver com o zeitgeist.

Outra possibilidade é o ureadahead, que foi interrompido segundos após esta mudança de tempo:

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

Acho que algum cronjob diário é responsável por essas alterações. Minha pasta 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

Agora vou focar no Google Chrome.

Por favor, deixe-me saber se você tem algumas idéias.

Atualização 5

OK, acho que os cronjobs não são o problema:

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

Eles correm às 06:25 am mas o atime muda depois.

Eu comparei os cronjobs do cron.daily com os de uma instalação limpa do Ubuntu.

Somente o send-poke e o google-chrome são diferentes. Mas o tempo em que os horários são alterados não se encaixa.

Eu removi send-poke, porque é algum tipo de informação de ping para canônico do ubuntu-oem-version.

Veja o código aqui:

apt-get source canonical-poke

Agora eu tenho que focar no tempo que o tempo muda. Se a mudança acontecer ontem às 4 da tarde, eu posso reiniciar ou desligar e inicializar meu pc até as 16h de hoje e nada acontecerá. Se eu inicializar após as 16h, o horário muda para o boothime. Então eu acho que isso muda min. depois de 24 horas.

Atualização 6

OK, talvez eu esteja errado com meus pensamentos sobre o atraso de 24 horas e os cronjobs. cat /proc/mounts | grep "/home/" me diz, minha pasta-mestra é montada com o relatime, então mudanças de atime são feitas min. depois de 24 horas. Eu acho que "zeitgeist" está de volta à mesa. Eu descobri que o zeitgeist não está instalado na minha instalação vanilla-ubuntu-16.04-x64. Mas no meu XPS13 está instalado (e desabilitado), mas é iniciado em cada inicialização.

    
por Alex 22.11.2016 / 15:29

1 resposta

1

Eu suponho que o seu diretório pessoal está criptografado usando o ecryptfs. Se isso realmente acontecer, o que você está vendo é o comportamento esperado , embora isso não seja muito óbvio.

O comportamento observado é o resultado de uma combinação de dois fatores:

  1. Sempre que você efetuar login, o ecryptfs precisará ler cada arquivo criptografado para obter a chave de criptografia do arquivo, que é armazenada no cabeçalho do arquivo. Veja man 7 ecryptfs . Isso deve alterar o último horário de acesso de cada arquivo para o horário em que você efetuou login, mas ...

  2. Por padrão, o Ubuntu, assim como a maioria das distribuições Linux, monta sistemas de arquivos ext4 com a opção relatime (veja man 8 mount ), o que significa que o tempo de acesso ao arquivo não é atualizado em todos os acessos. mas somente se for mais antigo que o tempo de alteração do arquivo ou pelo menos 24 horas após a última atualização. Isto é feito para evitar que todos os arquivos sejam lidos em uma leitura seguida por uma gravação, acelerando assim as operações e protegendo os dispositivos de armazenamento, e. SSDs, que são capazes de um número limitado de gravações durante sua vida útil.

por AlexP 28.11.2016 / 12:01