Вопрос или проблема
На хосте, работающем под управлением Ubuntu 20.04 LTS, я заметил, что по умолчанию journalctl (без привилегий root) эквивалентен journalctl --utc, но с привилегиями root journalctl учитывает часовой пояс (как показано с помощью timedatectl).
$ journalctl | tail -1 | tr -s ' ' | cut -d' ' -f 1-3
Sep 11 16:38:00
$ sudo journalctl | tail -1 | tr -s ' ' | cut -d' ' -f 1-3
Sep 11 13:38:13
$ timedatectl | grep "Time zone" | tr -s ' ' | cut -d' ' -f 5-6
(-03, -0300)
-
Я подозреваю, что Homebrew/linuxbrew является причиной, даже если
/home/linuxbrew/.linuxbrew/etc/systemd/journald.confимеет все строки закомментированы, но:$ which journalctl # systemd 253 (253) из --version /home/linuxbrew/.linuxbrew/bin/journalctl $ sudo which journalctl # systemd 245 (245.4-4ubuntu3.22) из --version /bin/journalctl -
Нет алиасов для
journalctl
В чем логика такого поведения?
Как я могу изменить это, чтобы по умолчанию journalctl всегда использовал текущий часовой пояс системы?
Проблема была связана с Homebrew. Он заменяет множество базовых инструментов на свои собственные. У меня уже были подобные проблемы с ним. Решением было просто полностью его удалить, так как его преимущества не стоили всех этих неожиданных глубоких изменений.
Также обратите внимание:
[!NOTE] Обратите внимание, что в отличие от macOS, Homebrew не использует песочницу при сборке на Linux, поэтому формулы могут устанавливаться за пределами префикса Homebrew.
Ответ или решение
В контексте управления системными журналами на Ubuntu 20.04 LTS можно столкнуться с такими неожиданностями, как разное поведение утилиты journalctl в зависимости от прав доступа. Одним из примеров является её использование в режиме без повышенных привилегий, когда по умолчанию отображаются метки времени в формате UTC, в то время как при запуске от имени root используются метки времени в соответствии с локальной временной зоной системы, установленной с помощью timedatectl. Разберёмся, почему так происходит.
Теория
journalctl — это утилита для просмотра системных и служебных журналов, собранных systemd-journald. Она может использоваться для вывода журналов с фильтрацией по различным критериям, включая диапазоны дат и временные зоны. Документация systemd утверждает, что поведение по умолчанию должно учитывать установленную в системе временную зону. Однако, это не всегда так по различным причинам.
Когда вы запускаете journalctl без привилегий root, она может быть настроена или заменена другой версией, которая по умолчанию использует UTC. Причиной этому может быть влияние сторонних утилит или пакетов, таких как Homebrew для Linux, влияющих на среду выполнения и конфигурацию.
Пример
Рассмотрим конкретную примерную ситуацию:
- Путь до используемой версии
journalctl(без root) — /home/linuxbrew/.linuxbrew/bin/journalctl, а путь до версии, используемой сsudo— /bin/journalctl. - В выводе
timedatectlуказана временная зона системы — (-03, -0300). Однако,journalctlбез прав root выводит время в UTC, хотя сsudoоно соответствует местному времени зоны. - Все строки в конфигурационном файле
/home/linuxbrew/.linuxbrew/etc/systemd/journald.confзакомментированы.
Это указывает на то, что Homebrew на Linux может заменять системные утилиты своими версиями, выполнение которых может иметь различия в логике работы. Особенно это заметно при недостаточности прав доступа.
Применение
Основной вопрос заключается в том, как исправить поведение по умолчанию journalctl, чтобы он всегда использовал текущую временную зону системы. Решение заключается в следующем:
- Проверить конфигурацию Homebrew: Убедитесь, что конфигурации в файлах по-другому не изменяют поведение
journalctl. - Редактирование путей PATH: Проверьте переменные окружения, такие как PATH, чтобы первыми в порядке поиска были оригинальные версии системных утилит из /bin или /usr/bin.
- Удаление Homebrew: Как и было сделано самим автором вопроса, можно рассмотреть вариант удаления Homebrew, если его присутствие влияет на поведение системы злополучным образом.
- Использование абсолютных путей: Можно явно указывать /bin/journalctl при вызове из командной строки, если хочется временно обойти проблему без изменения конфигурации Homebrew.
В заключение, важно понимать, что хотя такие инструменты, как Homebrew, могут принести удобство для управления пакетами, они также могут изменять поведение системы, к которому необходимо быть готовым и которое важно умело контролировать. В случае, если подобные средства усложняют поддержку и эксплуатацию систем, стоит рассмотреть их удаление или ограничение их использования. Подобные конфликты можно предотвратить, поддерживая документацию и регистрацию всех настроек и изменений, вносимых в систему, особенно для производственных сред.