/var/log/journal[Решено]

Запускайте journalctl -b и вы сразу получите лог за последнюю загрузку.
-b вместе с -u глючит (для большинства демонов только стоп-старт сообщения в логах выводит, и все), а это самый распространенный вариант у меня. Если б починили - было б супер.

А ротацию логов починили в 202ом systemd вроде, короче прям недавно совсем.
А ротацию логов починили в 202ом systemd вроде, короче прям недавно совсем.
Обратете внимание- SystemMaxUse=50M- на букову в конце
В вике не было раньше M -- мегобайтов
ivand
Обратете внимание- SystemMaxUse=50M- на букову в конце
В вике не было раньше M -- мегобайтов
не помню, что там было в вики, в мане было точно (ну или где то же я увидел эту букву xD)
PGP 0x31361F01
arcanisrepo
Лично мне с journal не повезло, с самого начала глюки — возможно, что-то делаю и не так, но особо не разбирался.
Думал, что это у всех так, поэтому пришлось затратить много усилий на получение нормальной информации.
Во первых, долго не мог получить все логи за прошлые запуски и дни.
Например выхлоп команд journalctl, journalctl -a, journalctl --all, journalctl -b — совершенно одинаков???????????? Аналогично и с Error.
А как мне почитать прошлые логи??????? И начались долгие чтения и поиски.
Для чтения логов за прошлые дни я использую команду sudo journalctl --directory=/var/log/journal --since=2013-..-...
Считал, что так делают все и считаю до сих пор (хотя этого быть не должно, так нужно читать логи, если Вы их убрали на хранение в другое место).
Во вторых, Вы пишете, что вопрос с ограничением размера решен, но опять же — не у меня
а)[…...@arch ~]$ sudo systemctl status systemd-journald.service
[sudo] password for …....:
systemd-journald.service - Journal Service
Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
…................
май 05 08:06:09 arch systemd-journal[124]: Allowing runtime journal files to grow to 148.4M.
май 05 08:06:09 arch systemd-journal[124]: Journal started
май 05 08:06:20 arch systemd-journal[124]: Allowing system journal files to grow to 50.0M.
…..........................

б)[…....@arch ~]$ sudo journalctl --disk-usage
Journals take up 1.1M on disk.

в)[…....@arch ~]$ du -sh /var/log/journal/
166M /var/log/journal/

г) journald.conf
#RateLimitBurst=200
SystemMaxUse=50M
#SystemKeepFree=
Ошибки не исчезают с опытом - они просто умнеют
Вы точно входите в группу systemd-journal ?
Natrio
Вы точно входите в группу systemd-journal ?

[......@arch ~]$ getent group | grep systemd-journal
systemd-journal:x:190:....

PS на всякий случай добавил повторно
[.....@arch ~]$ sudo gpasswd -a ..... systemd-journal
Добавление пользователя ...... в группу systemd-journal
[.......@arch ~]$ getent group | grep systemd-journal
systemd-journal:x:190:....

PSS На всякий случай сделал restart systemd-journald и перегрузился
все без изменений - грешу все-таки на глюк, или что-то упускаю. Но искать ошибки- очень кропотливая работа.

[......@arch ~]$ id
uid=1000(......) gid=100(users) группы=100(users) ......................,190(systemd-journal) - хотя, в принципе, это не к чему. Всеравно от root все должно было быть.
Ошибки не исчезают с опытом - они просто умнеют
В принципе, даже догадываюсь, где загвоздка - писал уже об этом в прошлом топике -
имеется еще временный журнал (на данную сессию, до перезагрузки) в /run/log/journal - даже размеры совпадают при выполнении journalctl --disk-usage
При запуске journalctl информация берется из временного журнала, а не из /var/log/journal.
Будет больше свободного времени, запущу strace и проанализирую логи.
PS - ошибка при копировании, исправил /run/systemd/journal на /run/log/journal
Ошибки не исчезают с опытом - они просто умнеют
Папка /run/log/journal отсутствует. Делаю трассировку.
Трассировка (не стал пока мудрить, сделал простую) показала следующее

execve("/usr/bin/journalctl", ["journalctl", "--all"], ) = 0
.....
openat(AT_FDCWD, "/run/log/journal", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/var/log/journal", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
......
read(4, "0634c7106b9b4f7aa45f3c7f5cd153f7", 32) = 32
close(4) = 0
openat(AT_FDCWD, "/var/log/journal/0634c7106b9b4f7aa45f3c7f5cd153f7", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
............

Что и должно, вобщем-то, быть - идет обращение и открытие лога только последней загрузки - 0634c7106b9b4f7aa45f3c7f5cd153f7.
Потому я и получаю при разных запросах одинаковые логи.
Но не понятен один момент, с размером этого лога, а именно
$ du -h /var/log/journal/0634c7106b9b4f7aa45f3c7f5cd153f7
1,2M /var/log/journal/0634c7106b9b4f7aa45f3c7f5cd153f7

$ journalctl --disk-usage
Journals take up 1.1M on disk.

Не может же по разному считаться.
Нужно будет копать дальше, искать где это все прописано.
А вообще интересно, что показывает трассировка у тех, у кого все работает правильно.
PS Не нужно проверять.
Уже проверил сам, своим запрсом journalctl --directory=/var/log/journal --since=2013-05-01
При трассировке идет последовательное обращение ко всем логам в папке /var/log/journal за указанную дату.
Ошибки не исчезают с опытом - они просто умнеют
Большая просьба ко Всем, прошу честно ответить на вопрос
- journal у Всех работает правильно? Или не работает правильно только у меня одного?

Это необходимо для того, чтобы определиться куда копать дальше, вплоть до переустановки.
Ошибки не исчезают с опытом - они просто умнеют
- journal у Всех работает правильно? Или не работает правильно только у меня одного?
Попробуй поставить вопрос поточнее...
А то написано много а в чем проблема то?
vasek
Но не понятен один момент, с размером этого лога, а именно
$ du -h /var/log/journal/0634c7106b9b4f7aa45f3c7f5cd153f7
1,2M /var/log/journal/0634c7106b9b4f7aa45f3c7f5cd153f7

$ journalctl --disk-usage
Journals take up 1.1M on disk.

Не может же по разному считаться.
Если в размере, то забей... +/- может зависеть от многих факторов...
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
 
Зарегистрироваться или войдите чтобы оставить сообщение.