Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Убунту

journalctl не постоянен И ‘Обнаружена смена времени. Сброс кэшей’, ‘Время прыгнуло назад, поворот’

На чтение 8 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Причина проблемы
  4. Шаги по устранению проблемы
  5. Дополнительные советы
  6. Заключение

Вопрос или проблема

Детали системы:

WSL2: Ubuntu 24.04.1
Win11: 23H2 сборка 22631.4037
Версия WSL: 2.2.4.0
Ядро: 5.15.153.1-microsoft-standard-WSL2

В ‘journalctl’ (‘dmesg’) и ‘syslog’ я вижу много сообщений ‘Обнаружена смена часов. Очистка кэшей.’ и ‘Время прыгнуло назад, вращение.’

См. Редактирование 2 ниже.
Похоже, что это началось вскоре (почти сразу) после обновления WSL2 с Ubuntu 22.04.5 на Ubuntu 24.04.1.
Я сделал обновление 2024-09-12 и получил сообщение “Обновление системы завершено.” в 17:40.

Я подозреваю, что это приводит к тому, что journalctl не ведет постоянные записи.
Даже при наличии /var/log/journal/ и настройке ‘Storage=persistent’ в ‘/etc/systemd/journald.conf’.
Старые сообщения journalctl, похоже, потеряны, даже после нескольких часов.

В чем может быть проблема?

На 13:00 самые старые сообщения, которые появляются, всего чуть больше часа назад:

$ journalctl 
15 сен 11:35:31 DESKTOP-E6DGEM9 systemd-resolved[292]: Обнаружена смена часов. Очистка кэшей.
15 сен 11:35:31 DESKTOP-E6DGEM9 systemd-journald[50]: Время прыгнуло назад, вращение.

При этом система работала более 15 часов:

$ uptime
 13:00:46 up 15:35,  2 users,  load average: 0.10, 0.05, 0.01

Пока я видел запись, начинающуюся с ‘Обнаружена смена часов. Очистка кэшей.’

Я пытался исправить это, удалив содержимое ‘/var/log/journal/’ с помощью:

systemctl status systemd-journald
sudo systemctl stop systemd-journald-dev-log.socket
sudo systemctl stop systemd-journald.socket
sudo systemctl stop systemd-journald
sudo rm /var/log/journal/* -rf
sudo systemctl start systemd-journald

но без изменений.

Впервые увидено в ‘/var/log/syslog’

2024-09-12T18:13:41.079123+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.
2024-09-12T18:13:41.079123+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.
2024-09-12T18:14:12.855185+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.
2024-09-12T18:14:44.510248+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.
2024-09-12T18:15:16.254113+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.
2024-09-12T18:15:47.900499+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.
2024-09-12T18:16:19.571240+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.
2024-09-12T18:16:51.214299+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.
2024-09-12T18:17:22.709058+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.
2024-09-12T18:17:54.230828+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.
2024-09-12T18:18:25.739595+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.

<пропущено>

2024-09-12T18:26:18.238966+02:00 DESKTOP-E6DGEM9 systemd-resolved[269]: Обнаружена смена часов. Очистка кэшей.
2024-09-12T18:26:18.240566+02:00 DESKTOP-E6DGEM9 kernel: systemd-journald[50]: Время прыгнуло назад, вращение.

Не уверен, связано ли это с синхронизацией времени.

NTP:

$ timedatectl
               Локальное время: Вс 2024-09-15 14:10:00 CEST
           Всемирное время: Вс 2024-09-15 12:10:00 UTC
                 Время RTC: Вс 2024-09-15 12:10:01
                Часовой пояс: Европа/Амстердам (CEST, +0200)
Системные часы синхронизированы: да
              Служба NTP: активна
          RTC в местном TZ: нет

$ timedatectl timesync-status
       Сервер: 185.125.190.57 (ntp.ubuntu.com)
Интервал опроса: 32с (мин: 32с; макс 34мин 8с)
         Ключ: нормальный
      Версия: 4
      Стратум: 2
    Справка: B7A08584
    Точность: 1мк (-25)
Корневая дистанция: 815мк (макс: 5с)
       Смещение: -2.699961с
        Задержка: 19.915мс
       Дёргание: 22.693мс
Количество пакетов: 1885
    Чистота: -43.497ppm

Редактирование 1 (2024-09-21):
Я создал резервную копию Ubuntu 24.04.1 и восстановил свою резервную копию Ubuntu 22.04.5.
С Ubuntu 22.04.5 журналирование ‘journalctl’ снова работает нормально:

$ journalctl -t systemd-resolved
10 сен 21:12:04 DESKTOP-E6DGEM9 systemd-resolved[210]: Положительные доверительные анкорные записи:
10 сен 21:12:04 DESKTOP-E6DGEM9 systemd-resolved[210]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
10 сен 21:12:04 DESKTOP-E6DGEM9 systemd-resolved[210]: Отрицательные доверительные анкорные записи: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-а>
10 сен 21:12:04 DESKTOP-E6DGEM9 systemd-resolved[210]: Используется системное имя хоста 'DESKTOP-E6DGEM9'.
-- Загрузка 6c5874aebd5d4e689223fd8c16b621db --
20 сен 20:32:24 DESKTOP-E6DGEM9 systemd-resolved[226]: Положительные доверительные анкорные записи:
20 сен 20:32:24 DESKTOP-E6DGEM9 systemd-resolved[226]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
20 сен 20:32:24 DESKTOP-E6DGEM9 systemd-resolved[226]: Отрицательные доверительные анкорные записи: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-а>
20 сен 20:32:24 DESKTOP-E6DGEM9 systemd-resolved[226]: Используется системное имя хоста 'DESKTOP-E6DGEM9'.

$ journalctl -t systemd-journald
10 сен 21:12:02 DESKTOP-E6DGEM9 systemd-journald[46]: Журнал начат
10 сен 21:12:02 DESKTOP-E6DGEM9 systemd-journald[46]: Время работы журнала (/run/log/journal/b745815e4a31140e822ee92b63e6aa28) составляет 8.0M, макс 388.4M, 380.4M свободно.
10 сен 21:12:02 DESKTOP-E6DGEM9 systemd-journald[46]: Время, затраченное на очистку до /var/log/journal/b745815e4a31140e822ee92b63e6aa28 составляет 8.963мс для 438 записей.
10 сен 21:12:02 DESKTOP-E6DGEM9 systemd-journald[46]: Системный журнал (/var/log/journal/b745815e4a31140e822ee92b63e6aa28) составляет 4.0G, макс 4.0G, 0B свободно.
-- Загрузка 6c5874aebd5d4e689223fd8c16b621db --
20 сен 20:32:23 DESKTOP-E6DGEM9 systemd-journald[46]: Журнал начат
20 сен 20:32:23 DESKTOP-E6DGEM9 systemd-journald[46]: Время работы журнала (/run/log/journal/b745815e4a31140e822ee92b63e6aa28) составляет 8.0M, макс 388.4M, 380.4M свободно.
20 сен 20:32:23 DESKTOP-E6DGEM9 systemd-journald[46]: Время, затраченное на очистку до /var/log/journal/b745815e4a31140e822ee92b63e6aa28 составляет 129.966мс для 438 записей.
20 сен 20:32:23 DESKTOP-E6DGEM9 systemd-journald[46]: Системный журнал (/var/log/journal/b745815e4a31140e822ee92b63e6aa28) составляет 3.3G, макс 4.0G, 659.8M свободно.

И самые старые сообщения с апреля:

$ sudo journalctl 
30 апр 21:09:01 DESKTOP-E6DGEM9 CRON[1789623]: pam_unix(cron:session): сеанс открыт для пользователя root(uid=0) (uid=0)
30 апр 21:09:01 DESKTOP-E6DGEM9 CRON[1789624]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && если [ ! -d /run/systemd/system ]; тогда /usr/lib/php/sessionclean; fi)
30 апр 21:09:01 DESKTOP-E6DGEM9 CRON[1789623]: pam_unix(cron:session): сеанс закрыт для пользователя root

Может, мне стоит рассмотреть возможность чистой установки Ubuntu 24.04.1 для следующей попытки…
/Редактирование 1

Редактирование 2 (2024-09-21)
Сравнивая с Ubuntu 22.04.5, я заметил следующее:

$ timedatectl
               Локальное время: Сб 2024-09-21 11:29:36 CEST
           Всемирное время: Сб 2024-09-21 09:29:36 UTC
                 Время RTC: Сб 2024-09-21 09:29:36
                Часовой пояс: Европа/Амстердам (CEST, +0200)
Системные часы синхронизированы: да
              Служба NTP: неактивна
          RTC в местном TZ: нет

Итак, с 22.04.5 служба NTP ‘неактивна’.
systemd-timesyncd.service не должен запускаться из-за: “Условие Virtualization=!container не выполнено”

$ systemctl status systemd-timesyncd.service
○ systemd-timesyncd.service - Синхронизация сетевого времени
     Загружено: загружено (/lib/systemd/system/systemd-timesyncd.service; включено; предустановка поставщика: включено)
     Активно: неактивно (мертв)
  Условие: условие запуска не выполнено в Сб 2024-09-21 11:30:29 CEST; 29мин назад
             └─ Условие Virtualization=!container не выполнено
       Документы: man:(8)

20 сен 20:32:24 DESKTOP-E6DGEM9 systemd[1]: Результат проверки условия привел к пропуску синхронизации сетевого времени.
21 сен 11:30:29 DESKTOP-E6DGEM9 systemd[1]: Результат проверки условия привел к пропуску синхронизации сетевого времени.

Итак, с Ubuntu 22.04.5 ‘systemd-timesyncd.service’ не запускается.

Но с 24.04.1 у меня было следующее:

10:51:04    17 сен 00:58:32 DESKTOP-E6DGEM9 systemd[1]: Запуск systemd-timesyncd.service - Синхронизация сетевого времени...
<пропущено>
10:51:04    17 сен 00:58:32 DESKTOP-E6DGEM9 systemd[1]: Запущено systemd-timesyncd.service - Синхронизация сетевого времени.

Это должно быть перед тем, как я вносил какие-либо изменения в настройки, связанные со временем.

Если кто-то сталкивается с той же проблемой, можете проверить с помощью systemctl status systemd-timesyncd.service, активна ли синхронизация сетевого времени?
/Редактирование 2

Я снова обновил до Ubuntu 24.04.1 и решил проблему следующими шагами:

systemctl status systemd-timesyncd.service
sudo systemctl stop systemd-timesyncd.service
# неактивен (мертв) с Вс 2024-09-29 20:26:55 CEST
sudo systemctl disable systemd-timesyncd.service

После остановки службы сообщения Обнаружена смена часов. Очистка кэшей. действительно прекратились.
Чтобы предотвратить запуск службы timesyncd, я также отключил ее.

journalctl -S "2024-09-29 20:00" -t systemd-resolved
# последнее сообщение: 29 сен 20:26:32

Ответ или решение

Для решения проблемы с журналом системы в WSL2 (Ubuntu 24.04.1), которая проявляется в сообщениях "Clock change detected. Flushing caches." и "Time jumped backwards, rotating", а также в отсутствии постоянных записей в journalctl, следуйте приведенным ниже шагам.

Причина проблемы

Проблема, скорее всего, связана с активированным сервисом Network Time Synchronization (systemd-timesyncd.service), который, судя по всему, вызывает сброс кэша и "перескок" времени. Это возникает из-за частого изменений системного времени, что мешает устойчивой работе системы ведения журналов.

Шаги по устранению проблемы

  1. Проверка состояния времени ситемы
    На начальном этапе проверим состояние службы синхронизации времени:

    systemctl status systemd-timesyncd.service

    Если служба активна, это может быть источником проблемы.

  2. Остановите службу синхронизации времени
    Если служба активна, ее необходимо остановить:

    sudo systemctl stop systemd-timesyncd.service

  3. Отключить автоматический запуск службы
    Чтобы предотвратить повторный запуск службы, отключите ее:

    sudo systemctl disable systemd-timesyncd.service

  4. Проверка изменений в журнале
    После выполнения вышеуказанных команд проверьте, исчезли ли сообщения о сбросе кэша. Для этого выполните:

    journalctl -t systemd-resolved

    Обратите внимание, что ваша последняя запись должна быть до того времени, когда проблемы начались.

  5. Сброс кэша журнала
    Если сообщения продолжают появляться, возможно, потребуется сбросить кэш журналов, выполнив:

    sudo systemctl restart systemd-journald

Дополнительные советы

  • Убедитесь, что ваше система времени (NTP) работает корректно и что ваш часовой пояс настроен правильно с использованием команды timedatectl.
  • Если проблема сохраняется, возможно, имеет смысл рассмотреть возможность выполнения чистой установки Ubuntu 24.04.1 в WSL2, если в процессе обновления возникли дополнительные проблемы с конфигурацией.

Заключение

После выполнения всех шагов, вы должны заметить улучшение. Остановка и отключение службы systemd-timesyncd должно устранить сообщения о сбросе времени и восстановить функциональность журнала. Убедитесь, что ваша система остается синхронизированной с временем, используя другие методы, если это необходимо.

24.04 windows-subsystem-for-linux
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности