SystemD

Начиная с версии 16.04, в Ubuntu сменилась система инициализации. Иногда это ведет к появлению 502 ошибки, потому что сервис Staffcop не стартует автоматически. Для решения этой проблемы нужно явно разрешить запуск данного юнита. sudo systemctl enable staffcop

Другие команды для юнитов: Незамедлительно запустить юнит:

systemctl start unit

Незамедлительно остановить юнит:

systemctl stop unit

Перезапустить юнит:

systemctl restart unit

Запросить у юнита перезагрузку его настроек:

systemctl reload unit

Показать статус юнита, а также запущен он или нет:

systemctl status unit

Проверить, включен ли юнит в автозапуск при загрузке системы:

systemctl is-enabled unit

Включить юнит в автозапуск при загрузке системы:

systemctl enable unit

Убрать юнит из автозапуска при загрузке системы:

systemctl disable unit

Маскировать юнит, чтобы сделать невозможным его запуск:

systemctl mask unit

Снять маску юнита:

systemctl unmask unit

Показать страницу справочного руководства, связанного с юнитом (необходима поддержка этой функции в указанном файле юнита):

systemctl help unit

Перезагрузить systemd для поиска новых или измененных юнитов:

systemctl daemon-reload

все логи с момента последний загрузки

journalctl -b

фильтруем по дате.

$ journalctl ---since yesterday
$ journalctl --since 09:00 --until now
$ journalctl --since 10:00 --until "1 hour ago"

фильтруем по службам

journalctl -u nginx.service

по службам за период времени.

journalctl -u nginx.service –since yesterday

journalctl -u nginx.service -u php-fpm.service —since today

по ID

journalctl _PID=381

по ID

journalctl _UID=33

кто есть в логах

journalctl -F _UID

все фильтры

man systemd.journal-fields

смотрим по пути

journalctl /usr/bin/docker

что там у ядра

journalctl -k

по уровню ошибок

journalctl -k

ошибки такие:

  • 0 — EMERG (система неработоспособна);

  • 1 — ALERT (требуется немедленное вмешательство);

  • 2 — CRIT (критическое состояние);

  • 3 — ERR (ошибка);

  • 4 — WARNING (предупреждение);

  • 5 — NOTICE (всё нормально, но следует обратить внимание);

  • 6 — INFO (информационное сообщение);

  • 7 — DEBUG (отложенная печать).

вывод без less

journalctl --no-pager

форматы логов.

journalctl  -u nginx.service -o json

вот такие

  • cat — только сообщения из логов без служебных полей;

  • export — бинарный формат, подходит для экспорта или резервного копирования логов;

  • short — формат вывода syslog;

  • short-iso — формат вывода syslog с метками времени в формате ISO 8601;

  • short-monotonic — формат вывода syslog c метками монотонного времени (monotonic timestamp);

  • short-precise — формат вывода syslog с метками точного времени (время событий указывается с точностью до микросекунд);

  • verbose — максимально подробный формат представления данных (включает даже те поля, которые в других форматах не отображаются).

недавние

journalctl -n

реал тайм

journalctl -f

скока логов?

journalctl --disk-usage

ужать логи до

sudo journalctl --vacuum-size=1G

ужать логи по времени

sudo journalctl --vacuum-time=1years

то же в конф файле

/еtc/systemd/journald.conf, which contain next parameters:

  • SystemMaxUse = максимальный объём, который логи могут занимать на диске;

  • SystemKeepFree = объём свободного места, которое должно оставаться на диске после сохранения логов;

  • SystemMaxFileSize = объём файла лога, по достижении которого он должен быть удален с диска;

  • RuntimeMaxUse = максимальный объём, который логи могут занимать в файловой системе /run;

  • RuntimeKeepFree = объём свободного места, которое должно оставаться в файловой системе /run после сохранения логов;

  • RuntimeMaxFileSize = объём файла лога, по достижении которого он должен быть удален из файловой системы /run.

Централизованное хранение логов

systemd-journal-remote --url https://some.host:19531/