Journalctl xe for details где посмотреть

Форум русскоязычного сообщества Ubuntu

Страница сгенерирована за 0.042 секунд. Запросов: 25.

Сайт
Об Ubuntu
Скачать Ubuntu
Семейство Ubuntu
Новости

Форум
Помощь
Правила

Документация
Пользовательская документация
Официальная документация
Семейство Ubuntu
Материалы для загрузки
Совместимость с оборудованием
RSS лента

Сообщество
Наши проекты
Местные сообщества
Перевод Ubuntu
Тестирование
RSS лента

Journald — система журналирования Systemd

Система журналирования systemd journald — бинарная система хранения служебной информации, которая появляется на stdout и stderr сервисов. Информация собирается journald, записывается и хранится.

В материале рассмотрены основные команды для journald, позволяющие находить необходимые данные по интересующему в конкретный момент сервису.

journald и отладка сервисов, запускаемых через systemd

Для просмотра логов используется утилита journalctl. Базовое ее использование описывается в подсказках, возникающих при, например, неудачном старте сервиса.

Рассмотрим запуск через systemctl сервиса docker.

A dependency job for docker.service failed. See ‘journalctl -xe’ for details.

Чтобы просмотреть отладочную информацию используем journalctl.

июн 10 14:07:15 vm-9999999 systemd[1]: Starting Docker Socket for the API.
июн 10 14:07:15 vm-9999999 systemd[31721]: docker.socket: Failed to resolve group docker: No such process
июн 10 14:07:15 vm-9999999 systemd[1]: docker.socket: Control process exited, code=exited status=216
июн 10 14:07:15 vm-9999999 systemd[1]: docker.socket: Failed with result ‘exit-code’.
июн 10 14:07:15 vm-9999999 systemd[1]: Failed to listen on Docker Socket for the API.
— Unit docker.socket has failed.
июн 10 14:07:15 vm-9999999 systemd[1]: Dependency failed for Docker Application Container Engine.
— Unit docker.service has failed.

июн 10 14:07:15 vm-9999999 systemd[1]: docker.service: Job docker.service/start failed with result ‘dependency’.

В данном случае Docker не запускается из-за проблем с зависимостями.

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

Параметры журналирования systemd journald можно изменить в /etc/systemd/journald.conf. Все его директивы по умолчанию закомментированы.

Поскольку systemd оперирует понятием unit, все логи выводятся с указанием этого unit-а. Например, для Nginx

Ключ -b означает, что требуется информация с момента последней загрузки системы

Также часто нужны сообщения ядра, чтобы увидеть их добавляется ключ -k

В отличие от стандартных систем информация не пишется в заданный лог файл, а выводится непосредственно в консоль. Информация передается в less и ее нельзя обрабатывать стандартными средствами вроде grep или sed.

Поменять это поведение можно так

Другие опции journalctl, которые очень часто используются

Вывод списка загрузок системы, цифры затем можно передавать вместе с ключем -b

И по бинарному файлу

Также можно гибко задавать время, за которое требуется информация

journalctl —since 06:00 —until «1 hour ago»

Просмотр информации о системных процессах в режиме реального времени

Список всех возможных фильтров всегда доступен в справке

Эти команды journald являются базовыми и их в большинстве случаев достаточно для отладки сервисов, которые запускает systemd.

Nginx не стартует, но проверка конфига не показывает ошибок?

Nginx 1.12.0, Linux RH 7.2
Установил, сделал конфиг — проверка конфига выдает что все ок:

nginx: the configuration file /etc/nginx/conf.d/ev1.conf syntax is ok
nginx: configuration file /etc/nginx/conf.d/ev1.conf test is successful

Запускаю, выдает ошибку:

systemctl start nginx.service
Job for nginx.service failed because the control process exited with error code. See «systemctl status nginx.service» and «journalctl -xe» for details.

Starting nginx — high performance web server.
nginx: [emerg] «events» directive is not allowed here in /etc/nginx/conf.d/ev1.conf:1
nginx: configuration file /etc/nginx/nginx.conf test failed
nginx.service: control process exited, code=exited status=1

Запускаю со стандартным конфигом — запускается без ошибок. Возвращаю конфиг — снова ошибки. Как понять что не так с конфигом (тест конфига проходит нормально).

Вопрос задан более трёх лет назад
41228 просмотров

Комментировать
Решения вопроса 2

Endru9

Админ Linux

«events» directive is not allowed here in /etc/nginx/conf.d/ev1.conf:1

вот говорит же.
проверка nginx делается командой:
nginx -t
Ответ написан более трёх лет назад
Комментировать
Нравится 4 Комментировать
Админю сервера, починяю примуса.

А вы проверяйте не один отдельно взятый, а делайте nginx -t и проверяйте все конфиги. Судя по всему у вас этот конфиг инклюдится из другого и тогда приходит нарушение расположения директивы.
events может быть только в main, а вы засунули куда-нибудь внутрь конфигов хостов.
переносите в nginx.conf или инклюдьте из верного места в nginx.conf.

Ответ написан более трёх лет назад
Комментировать
Нравится 2 Комментировать
Ответы на вопрос 2
проверь от имени юзера под которым стартует nginx в systemd
к примеру
sudo -u %user% nginx -t
Ответ написан более трёх лет назад
Нравится 1 13 комментариев

nginx стартует от рута и потом понижает свои права, так как мэйнтейнеры всех дистрибутивов ленивы и не используют setcap, что бы разрешить nginx’у биндиться на порты 1-1024. Ваш совет не имеет смысла.

Erelecano Oioraen: ой да ладно, не говорите за всех. дефолтный конфиг от убунты 16.04.2 годичной давности.
За старт несистемных демонов от рута руки еще в детском садике должны отбивать.
вопрос2: а вы чем пользуетесь ??

***@srv3:~$ systemctl cat nginx.service # /lib/systemd/system/nginx.service # Stop dance for nginx # ======================= # # ExecStop sends SIGSTOP (graceful stop) to the nginx process. # If, after 5s (--retry QUIT/5) nginx is still running, systemd takes control # and sends SIGTERM (fast shutdown) to the main process. # After another 5s (TimeoutStopSec=5), and if nginx is alive, systemd sends # SIGKILL to all the remaining processes in the process group (KillMode=mixed). # # nginx signals reference doc: # http://nginx.org/en/docs/control.html # [Unit] Description=A high performance web server (www-data) After=network.target [Service] User=www-data Group=www-data Type=forking PIDFile=/run/nginx.pid PermissionsStartOnly=true #ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;' ExecStartPre=/bin/touch /run/nginx.pid ExecStartPre=/bin/chown www-data:www-data /run/nginx.pid ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;' ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid TimeoutStopSec=5 KillMode=mixed [Install] WantedBy=multi-user.target

pfg21: а теперь посмотрите что делает nginx -g. А именно стартует родительский процесс от рута, что бы открыть порты и понижает детям права, делая их www-data. Ну сделайте вы ps aufxw|grep nginx и обнаружьте, что папа запускается от рута.
Для того, что бы запускаться не от рута нужно сделать cap_net_bind_service=+ep /usr/bin/nginx и пускать его сразу от пользователя, без -g.

Erelecano Oioraen: тогда почитайте доки системд по теме от каких пользователей стартует ExecStart при наличии настроек User=www-data

ps aufxw|grep nginx

*** 3791 0.0 0.1 6352 876 pts/0 S+ 13:44 0:00 \_ grep --color=auto nginx www-data 764 0.0 0.0 6604 472 ? Ss 09:03 0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; www-data 765 0.0 0.1 6768 920 ? S 09:03 0:00 \_ nginx: worker process

pfg21: еще раз, для тех кто на бронепоезде. Посмотрите от кого у вас запущен родительский процесс. Без рута или cap_net_bind_service=+ep вы не сможете занять 80 и 443 порты.

Erelecano Oioraen: повторю
ps aufxw|grep nginx

*** 3791 0.0 0.1 6352 876 pts/0 S+ 13:44 0:00 \_ grep --color=auto nginx www-data 764 0.0 0.0 6604 472 ? Ss 09:03 0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; www-data 765 0.0 0.1 6768 920 ? S 09:03 0:00 \_ nginx: worker process

Erelecano Oioraen: норм, моя ошибка.
в текущем конфиге рабочий порт больше 1024.
listen 80 обламывает запуск nginx

Как я уже писал это обходится при помощи setcap, все думаю, что надо бы собрать nginx под Debian/Ubuntu с ним, что бы и родитель не под рутом пускался, но руки не доходят. Самого раздражает, что всем кто работает с портами 1-1024 нужен рутовый родитель и что мэйнтейнеры не используют setcap.

зачем ?? дописать libcap2-bin в Pre-Depends и соотвествующий setcap в postinst
видать почему-то не хочуть.

pfg21: дело не в том, что не хотят, дело в том, что им лень. Обычная костность мышления. А под пересобрать собственно примерно это и имелось в виду. Собрать свой пакет так, что бы оно шло с setcap из коробки, ну и подправить дефолтный конфиг и прочее.

Erelecano Oioraen: поковырял тут systemd, в нем оказывается есть поддержка capablies
как понимаю надо просто дописать строчку в сервис
———— man systemd.exec
CapabilityBoundingSet=
Controls which capabilities to include in the capability bounding set for the executed process. See capabilities(7) for details. Takes a whitespace-separated list of capability names as read by cap_from_name(3), e.g. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. Capabilities listed will be included in the bounding set, all others are removed. If the list of capabilities is prefixed with «~», all but the listed capabilities will be included, the effect of the assignment inverted. Note that this option also affects the respective capabilities in the effective, permitted and inheritable capability sets, on top of what Capabilities= does. If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced. This option may appear more than once, in which case the bounding sets are merged. If the empty string is assigned to this option, the bounding set is reset to the empty capability set, and all prior settings have no effect. If set to «~» (without any further argument), the bounding set is reset to the full set of available capabilities, also undoing any previous settings.

у меня чегой-то не прокатили, мож разберешься ??

Шпаргалка по journalctl в Linux

Журналы — это один из самых важных источников информации при возникновении любых ошибок в операционной системе Linux. Я это уже много раз говорил ранее и вот сказал ещё раз. Раньше в Linux для сохранения журналов сервисов использовался отдельный демон под названием syslogd. Но с приходом системы инициализации systemd большинство функций касающихся управления сервисами перешли под её управление. В том числе и управление логами.

Теперь для просмотра логов определенного сервиса или загрузки системы необходимо использовать утилиту journalctl. В этой статье мы разберем примеры использования journalctl, а также основные возможности этой команды и её опции. По сравнению с обычными файлами журналов, у journalctl есть несколько преимуществ. Все логи находятся в одном месте, они индексируются и структурируются, поэтому к ним можно получить доступ в нескольких удобных форматах.

Table of Contents

Синтаксис и опции journalctl
Горячие клавиши journalctl
Шпаргалка по journalctl
- 1. Просмотр логов сервисов
- 2. Просмотр логов в режиме tail
- 3. Просмотр логов загрузки
- 4. Фильтрация по дате
- 5. Журнал ядра
- 6. Настройка формата вывода
- 7. Очистка логов
Синтаксис и опции journalctl

Синтаксис команды очень простой. Достаточно выполнить команду без опций или передав ей нужные опции. Если утилита не выводит ничего, выполните её от имени суперпользователя:

journalctl опции

А теперь давайте разберем основные опции journalctl:
- —full, -l — отображать все доступные поля;
- —all, -a — отображать все поля в выводе full, даже если они содержат непечатаемые символы или слишком длинные;
- —pager-end, -e — отобразить только последние сообщения из журнала;
- —lines, -n — количество строк, которые нужно отображать на одном экране, по умолчанию 10;
- —no-tail — отображать все строки доступные строки;
- —reverse, -r — отображать новые события в начале списка;
- —output, -o — настраивает формат вывода лога;
- —output-fields — поля, которые нужно выводить;
- —catalog, -x — добавить к информации об ошибках пояснения, ссылки на документацию или форумы там, где это возможно;
- —quiet, -q — не показывать все информационные сообщения;
- —merge, -m — показывать сообщения из всех доступных журналов;
- —boot, -b — показать сообщения с момента определенной загрузки системы. По умолчанию используется последняя загрузка;
- —list-boots — показать список сохраненных загрузок системы;
- —dmesg, -k — показывает сообщения только от ядра. Аналог вызова команды dmesg;
- —identifier, -t — показать сообщения с выбранным идентификатором;
- —unit, -u — показать сообщения от выбранного сервиса;
- —user-unit — фильтровать сообщения от выбранной сессии;
- —priority, -p — фильтровать сообщения по их приоритету. Есть восемь уровней приоритета, от 0 до 7;
- —grep, -g — фильтрация по тексту сообщения;
- —cursor, -c — начать просмотр сообщений с указанного места;
- —since, -S, —until, -U — фильтрация по дате и времени;
- —field, -F — вывести все данные из выбранного поля;
- —fields, -N — вывести все доступные поля;
- —system — выводить только системные сообщения;
- —user — выводить только сообщения пользователя;
- —machine, -M — выводить сообщения от определенного контейнера;
- —header — выводить заголовки полей при выводе журнала;
- —disk-usage — вывести общий размер лог файлов на диске;
- —list-catalog — вывести все доступные подсказки для ошибок;
- —sync — синхронизировать все не сохраненные журналы с файловой системой;
- —flush — перенести все данные из каталога /run/log/journal в /var/log/journal;
- —rotate — запустить ротацию логов;
- —no-pager — выводить информацию из журнала без возможности листать страницы;
- -f — выводить новые сообщения в реальном времени, как в команде tail;
- —vacuum-time — очистить логи, давностью больше указанного периода;
- —vacuum-size — очистить логи, чтобы размер хранилища соответствовал указанному.
Горячие клавиши journalctl

По умолчанию информация лога выводится в формате, в котором её можно листать. Давайте разберем горячие клавиши, которые вы можете для этого использовать:
- Стрелка вниз, Enter, e или j — переместиться вниз на одну строку;
- Стрелка вверх, y или k — переместиться на одну строку вверх;
- Пробел — переместиться на одну страницу вниз;
- b — переместиться на одну страницу вверх;
- Стрелка вправо, стрелка влево — горизонтальна прокрутка;
- g — перейти на первую строку;
- G — перейти на последнюю строку;
- p — перейти на позицию нужного процента сообщений. Например, 50p перенесет курсор на середину вывода;
- / — поиск по журналу;
- n — найти следующее вхождение;
- N — предыдущее вхождение;
- q — выйти.
Теперь вы знаете основные опции команды и клавиши, с помощью которых можно ею управлять. Дальше небольшая шпаргалка journalctl.

Шпаргалка по journalctl

Вывод journalctl представляет из себя цельный список всех сохраненных сообщений. Если вы запустите команду journalctl без параметров, то получите самые первые сообщения, которые были сохранены. В моем случае это данные за 13 января:

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

янв 13 20:55:55 sergiy-pc kernel: Linux version 4.15.0-43-generic
- янв 13 20:55:55 — дата и время события;
- sergiy-pc — хост, на котором произошло событие;
- kernel — источник события, обычно это программа или сервис. В данном случае ядро;
- Linux version 4.15.0-43-generic — само сообщение.
Давайте перейдем к примерам фильтрации и перемещения.

1. Просмотр логов сервисов

Самый частый случай использования journalctl — это когда вы пытаетесь запустить какой-либо сервис с помощью systemd, он не запускается и systemd выдает вам такое сообщение подобного содержания: Failed to start service use journalctl -xe for details. Система сама предлагает вам какую команду надо выполнить:

sudo journalctl -xe

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

Чтобы отфильтровать сообщения только от определенного сервиса можно использовать опцию -u. Например:

sudo journalctl -eu apache2.service

2. Просмотр логов в режиме tail

С помощью опции -f можно указать утилите, что необходимо выводить новые сообщения в реальном времени:

sudo journalctl -f

В этом режиме less не поддерживается, поэтому для выхода нажмите сочетание клавиш Ctrl+C.

3. Просмотр логов загрузки

В логе journalctl содержатся все логи, в том числе и логи загрузки. Для того чтобы открыть лог последней загрузки используйте опцию -b:

sudo journalctl -b

Посмотреть список всех сохраненных загрузок можно командой:

sudo journalctl -list-boots

Теперь, чтобы посмотреть сообщения для нужной загрузки используйте её идентификатор:

sudo journalctl -b 37d5c906c9c6404682f029b2c34ec9dc

4. Фильтрация по дате

С помощью опции —since вы можете указать дату и время, начиная с которой нужно отображать логи:

sudo journalctl —since «2019-01-20 15:10:10»

Опция —until помогает указать по какую дату вы хотите получить информацию:

sudo journalctl -e —until «2019-01-20 15:05:50»

Или сразу скомбинируем две эти опции чтобы получить логи за нужный период:

sudo journalctl —since «2019-01-20 15:10:10» —until «2019-01-20 15:05:50»

Кроме даты в формате YYYY-MM-DD в этих опциях можно использовать такие слова, как yesterday, today, и tomorrow. Также допустимы конструкции 1 day ago (один день назад) или 3 hours ago (три часа назад). Ещё можно использовать знаки + и -. Например -1h30min будет означать полтора часа назад.

5. Журнал ядра

Если вы хотите посмотреть только сообщения ядра используйте опцию -k:

sudo journalctl -ek

6. Настройка формата вывода

По умолчанию journalctl выводит информацию с помощью утилиты less, в которой вы можете её удобно листать и просматривать. Но формат вывода можно изменить:
- short — используется по умолчанию;
- verbose — также, как и short, только выводится намного больше информации;
- json — вывод в формате json, одна строка лога в одной строке вывода;
- json-pretty — форматированный вывод json для более удобного восприятия;
- cat — отображать только сообщения, без метаданных.
Чтобы указать нужный формат используйте опцию -o. Например:

sudo journalctl -o json-pretty

sudo journalctl -eo json-pretty

7. Очистка логов

Сначала нужно посмотреть сколько ваши логи занимают на диске. Для этого используйте такую команду:

sudo journalctl —disk-usage

Чтобы уменьшить размер лога можно использовать опцию —vacuum-size. Например, если вы хотите, чтобы ваши файлы журналов занимали на диске не более 2 Гб, выполните команду:

sudo journalctl —vacuum-size=2G

Теперь старые логи будут удалены, пока общий объем хранилища не будет составлять 2 гигабайта. Также можно удалять логи по времени. Для этого используется опция —vacuum-time. Например, оставим только логи за последний год:

Выводы

В этой статье мы разобрали как пользоваться journalctl в Linux. Наличие этой утилиты в системе не означает, что теперь вы не можете пользоваться обычными файлами логов. Большинство сервисов как и раньше пишут свои основные логи в файлы, а в лог journalctl пишутся сообщения при старте сервисов, а также различные системные сообщения.
Похожие публикации: