Início / unix / Perguntas / 775999
Accepted
U. Windl
Asked: 2024-05-07 18:00:17 +0800 CST

Quem muda `/proc/sys/kernel/random/boot_id` no Linux (SLES)?

  • 772

Bem, pensei que fosse lógico que o kernel mudasse /proc/sys/kernel/random/boot_iddurante a inicialização e depois mantivesse esse valor durante a execução. Pelo menos isso faria sentido para mim se o uso pretendido boot_idfosse descobrir quando a máquina foi reinicializada.

Ao monitorar o arquivo usando monit, notei que o arquivo parece mudar mesmo que a máquina não tenha reiniciado; isso significa que o carimbo de data/hora do arquivo muda, não o conteúdo.

Então, eu me pergunto quem altera os carimbos de data/hora do arquivo.

Para referência, aqui está minha configuração do monit sendo usada:

  check file bootid with path /proc/sys/kernel/random/boot_id
    #if changed timestamp then alert
    if content !=
       "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}"
    then alert
    if changed checksum then alert
    group local

Ao verificar os resultados do monitoramento, obtive:

File 'bootid'
  status                       OK
  monitoring status            Monitored
  monitoring mode              active
  on reboot                    start
  permission                   444
  uid                          0
  gid                          0
  size                         0 B
  access timestamp             Tue, 07 May 2024 11:01:31
  change timestamp             Tue, 07 May 2024 11:01:31
  modify timestamp             Tue, 07 May 2024 11:01:31
  content match                no
  checksum                     d174a6b860689b62417af5eccd2b17ee (MD5)
  data collected               Tue, 07 May 2024 11:46:11

Verificação cruzada que obtive:

# stat /proc/sys/kernel/random/boot_id
  File: '/proc/sys/kernel/random/boot_id'
  Size: 0               Blocks: 0          IO Block: 1024   regular empty file
Device: 4h/4d   Inode: 9770501     Links: 1
Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-05-07 11:01:31.721335498 +0200
Modify: 2024-05-07 11:01:31.721335498 +0200
Change: 2024-05-07 11:01:31.721335498 +0200
 Birth: -
# uptime
 11:49am  up 14 days  0:49,  4 users,  load average: 0.00, 0.00, 0.00

O sistema está executando SLES12 SP5 em x86_64, e os únicos "suspeitos" são cron-jobs e "snapper":

May 07 11:00:01 v04 systemd[1]: Started Session 7426 of user root.
May 07 11:00:01 v04 systemd[1]: Started Session 7428 of user root.
May 07 11:00:01 v04 systemd[1]: Started Session 7427 of user root.
May 07 11:00:01 v04 CRON[5541]: (root) CMD ([ -x /usr/lib64/sa/sa1 ] && exe
May 07 11:00:01 v04 run-crons[5606]: suse.de-snapper: OK
linux

2 respostas

  1. Best Answer

    Os carimbos de data e hora /procnão são realmente significativos. Em particular, a hora da modificação não indica quando o conteúdo muda. Não consigo encontrar documentação oficial sobre isso, mas, a partir de uma rápida análise da fonte, parece que todos os três carimbos de data e hora (atime, mtime, ctime) são definidos quando o inode é criado e nunca são atualizados.

    Os inodes são criados sob demanda. A demanda pode ser uma tentativa de ler o arquivo, uma tentativa de gravar no arquivo ou uma chamada stat( ls -l) no arquivo. Para alguns arquivos pode haver uma demanda interna por um valor que preencha um cache de dados e também crie a entrada do inode, mas não acho que isso se aplique aos /proc/sys/kernel/random/*quais são descritos como “botões herdados parcialmente não utilizados”.

    Portanto, o mtime na /procentrada provavelmente é a primeira vez que um aplicativo deseja o valor ou a primeira vez que seu software de monitoramento o atinge, o que ocorrer primeiro. Ou pode ser mais recente se o inode for removido do cache de arquivos. Em qualquer caso, pode ser arbitrariamente mais antigo ou mais recente que a criação do conteúdo.

    O boot_idvalor é gerado na primeira vez que o arquivo é lido e depois mantido na memória para sempre, pois deve estar estável até a próxima reinicialização.

    De qualquer forma, monitorar /procnão faz sentido. Estes não são arquivos reais, é conteúdo gerado sob demanda.

    • 8

  2. Basicamente https://unix.stackexchange.com/a/776000/320598 está certo, e fiz uma experiência para verificar (veja também /usr/src/linux/Documentation/sysctl/vm.txt):

    • echo 1 > /proc/sys/vm/drop_caches( pagecache gratuito ) não teve efeito
    • echo 2 > /proc/sys/vm/drop_caches( objetos de laje recuperáveis ​​​​gratuitos (inclui dentries e inodes) ) causou uma atualização de carimbos de data / hora
    • echo 3 > /proc/sys/vm/drop_caches( objetos de laje livres e pagecache ) causou uma atualização de carimbos de data/hora
    • 4

relate perguntas