systemd отключение journald
Это не значит что демон отключен. Он работает и перенаправляет логи, как тебе и сказали.
vurdalak ★★★★★
( 10.02.16 16:34:40 MSK )
Ответ на: комментарий от vurdalak 10.02.16 16:34:40 MSK
если я сделаю systemctl mask systemd-journald.service
получу что?
carter ★
( 10.02.16 16:38:28 MSK ) автор топика
Ответ на: комментарий от carter 10.02.16 16:38:28 MSK
Попробуй и узнаешь. Я не рисковал так.
vurdalak ★★★★★
( 10.02.16 16:38:48 MSK )
Ответ на: комментарий от vurdalak 10.02.16 16:34:40 MSK
«Начиная с systemd версии 216 эта опция была отключена по-умолчанию, так как rsyslog и syslog-ng уже могут читать самостоятельно сообщения journal. »
Ну хотя бы логи в бинарном виде хранить не будет.
carter ★
( 10.02.16 16:39:56 MSK ) автор топика
Ответ на: комментарий от carter 10.02.16 16:38:28 MSK
Система через некоторое время тихо умрёт. Выяснение того, почему (и как это обойти), остаётся в качестве упражнения юному хейтеру бинарных логов :3
intelfx ★★★★★
( 10.02.16 16:52:23 MSK )
Последнее исправление: intelfx 10.02.16 16:52:53 MSK (всего исправлений: 1)
Ответ на: комментарий от intelfx 10.02.16 16:52:23 MSK
блин, мне даже интересно стало
arcanis ★★★★
( 10.02.16 21:59:26 MSK )
Ответ на: комментарий от arcanis 10.02.16 21:59:26 MSK
Yeah, don’t do that, atleast not by itself. Masking systemd-journald causes all kinds of dependency failures and drops you at an emergency prompt.
arcanis ★★★★
( 10.02.16 22:01:07 MSK )
Ответ на: комментарий от intelfx 10.02.16 16:52:23 MSK
не использовать systemd. Тоже мне тайна 😀
Deleted
( 10.02.16 22:18:58 MSK )
Ответ на: комментарий от Deleted 10.02.16 22:18:58 MSK
Не пытайся убедить этого фанбоя что систумд зло, это бесполезно. У меня иногда возникает чувство что он Поцтеру даже свечку держать согласится.
ТС, забей на эту тухлую штуку, поставь генту и не сношай себе мозг
upcFrost ★★★★★
( 10.02.16 23:41:46 MSK )
Ответ на: комментарий от upcFrost 10.02.16 23:41:46 MSK
Не, я подтруниваю.
После того, как увидел что он преднамеренно дезинформирует людей — и убедить и убеждаться перестал 🙂
Deleted
( 11.02.16 00:50:27 MSK )
Ответ на: комментарий от intelfx 10.02.16 16:52:23 MSK
что значит умрет?
я не хейтер бинарных логов. просто стало интересно.
carter ★
( 11.02.16 10:38:24 MSK ) автор топика
Ответ на: комментарий от carter 11.02.16 10:38:24 MSK
Если просто замаскировать systemd-journald, через некоторое время все программы, которые хоть что-то в него пишут (даже косвенно), начнут поочерёдно падать (как кошки с неба в конце второго Postal’а).
intelfx ★★★★★
( 11.02.16 11:29:28 MSK )
Ответ на: комментарий от intelfx 11.02.16 11:29:28 MSK
не не, замаскировать это то понятно.
я отключил, чтобы просто не писал в бинарный файл
carter ★
( 11.02.16 12:06:08 MSK ) автор топика
Ответ на: комментарий от carter 11.02.16 12:06:08 MSK
Я говорю о том, что можно даже замаскировать. Просто нужно учесть некоторую особенность.
intelfx ★★★★★
( 11.02.16 12:41:10 MSK )
Ответ на: комментарий от intelfx 11.02.16 12:41:10 MSK
я понял, спасибо.
carter ★
( 11.02.16 12:42:34 MSK ) автор топика
Ответ на: комментарий от intelfx 10.02.16 16:52:23 MSK
Система через некоторое время тихо умрёт.
AS ★★★★★
( 12.02.16 10:18:22 MSK )
Ответ на: комментарий от arcanis 10.02.16 21:59:26 MSK
Всё просто: journald же сокет-активируемый. Приложения всё равно будут писать в заботливо заранее открытый сокет и через какое-то время переполнят внутриядерный буфер. Другими словами, надо вместе с .service замаскировать ещё и .socket.
intelfx ★★★★★
( 12.02.16 10:23:14 MSK )
Ответ на: комментарий от AS 12.02.16 10:18:22 MSK
Естественно. Если лезть в кишки любого достаточно сложного софта без должного понятия о том, как эти кишки устроены — то в любом случае рано или поздно получишь unexpected behavior.
intelfx ★★★★★
( 12.02.16 13:15:04 MSK )
Ответ на: комментарий от intelfx 12.02.16 13:15:04 MSK
по этой причине systemd и не любят.
carter ★
( 12.02.16 14:57:10 MSK ) автор топика
Ответ на: комментарий от carter 12.02.16 14:57:10 MSK
По какой? По той, что это «достаточно сложный софт»? Это проблема мозга администратора, а не софта.
intelfx ★★★★★
( 12.02.16 15:04:35 MSK )
Ответ на: комментарий от intelfx 12.02.16 15:04:35 MSK
он большой. много того что мне не нужно.
carter ★
( 12.02.16 15:25:16 MSK ) автор топика
Ответ на: комментарий от intelfx 12.02.16 15:04:35 MSK
По той, что это «достаточно сложный софт» ?
Совершенно верно. ПО такой сложности не должно быть в основе функционирования ОС.
И да, это проблема мозга архитектора ОС.
AS ★★★★★
( 12.02.16 15:25:45 MSK )
Последнее исправление: AS 12.02.16 15:26:45 MSK (всего исправлений: 1)
Ответ на: комментарий от AS 12.02.16 15:25:45 MSK
наверно всех раздражает скорее отсутствие выбора. а точнее с упорством навязывают, выглядит странно и подозрительно.
carter ★
( 12.02.16 15:30:02 MSK ) автор топика
Ответ на: комментарий от carter 12.02.16 15:30:02 MSK
Раздражает скорее неустойчивое, переусложненное Д. Против всяких upstart и т.д. не было такого шума. Вот например мне не нужна система инициализации которая в любой момент может «что-то» сделать не то и в результате уронить систему, причем даже на десктопе, когда открыты необходимые для работы приложения и вдруг «фигак» получить не хочется. Вобщем раздражает ненадежность.
anc ★★★★★
( 12.02.16 17:16:31 MSK )
Ответ на: комментарий от carter 12.02.16 15:30:02 MSK
наверно всех раздражает скорее отсутствие выбора
Тогда уж вместе. Да, можно было бы не обращать внимания на комбайн (который просто не может быть надёжен из-за перегруженности функционалом), если бы он, дополнительно, не тянул на себя одеяло.
systemd (Русский)/Journal (Русский)
Состояние перевода: На этой странице представлен перевод статьи systemd/Journal. Дата последней синхронизации: 10 декабря 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.
systemd использует журнал (journal), собственную систему ведения логов, в связи с чем больше не требуется запускать отдельный демон логирования. Для чтения логов используйте команду journalctl(1) .
В Arch Linux каталог /var/log/journal/ — это часть пакета systemd и по умолчанию (когда в конфигурационном файле /etc/systemd/journald.conf параметру Storage= задано значение auto ) журнал записывается именно в /var/log/journal/ . Если каталог будет удалён, systemd не пересоздаст его автоматически и вместо этого будет вести журнал в /run/systemd/journal без сохранения между перезагрузками. Однако каталог будет пересоздан, если добавить Storage=persistent в journald.conf и перезапустить systemd-journald.service (или перезагрузиться).
Сообщения в журнале классифицируются по уровню приоритета и категории (Facility). Классификация записей соответствует классическому протоколу Syslog (RFC 5424).
Уровни приоритета
Коды важности syslog (в systemd называются приоритетами) используются для пометки важности сообщений RFC 5424.
| Значение | Важность | Ключевое слово | Описание | Примеры |
|---|---|---|---|---|
| 0 | Emergency | emerg | Cистема не работоспособна | Серьёзный баг в ядре, дамп памяти systemd. Данный уровень не должен использоваться приложениями. |
| 1 | Alert | alert | Cистема требует немедленного вмешательства | Отказ важной подсистемы. Потеря данных. kernel: BUG: unable to handle kernel paging request at ffffc90403238ffc . |
| 2 | Critical | crit | Cостояние системы критическое | Аварийные отказы, дампы памяти. Например, знакомое сообщение: systemd-coredump[25319]: Process 25310 (plugin-containe) of user 1000 dumped core Отказ основных приложений системы, например, X11. |
| 3 | Error | err | Cообщения об ошибках | Сообщение о некритической ошибке: kernel: usb 1-3: 3:1: cannot get freq at ep 0x84 , systemd[1]: Failed unmounting /var. , libvirtd[1720]: internal error: Failed to initialize a valid firewall backend |
| 4 | Warning | warning | Предупреждения о возможных проблемах | В некорневой файловой системе остался всего 1 ГБ свободного места. org.freedesktop. Notifications[1860]: (process:5999): Gtk-WARNING **: Locale not supported by C library. Using the fallback ‘C’ locale . |
| 5 | Notice | notice | Cообщения о нормальных, но важных событиях | systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway , gcr-prompter[4997]: Gtk: GtkDialog mapped without a transient parent. This is discouraged |
| 6 | Informational | info | Информационные сообщения | lvm[585]: 7 logical volume(s) in volume group «archvg» now active |
| 7 | Debug | debug | Отладочные сообщения | kdeinit5[1900]: powerdevil: Scheduling inhibition from «:1.14» «firefox» with cookie 13 and reason «screen» |
Вышеуказанные правила являются рекомендацией и окончательное решение остаётся за разработчиком приложения. Всегда возможно, что сообщение будет выше или ниже ожидаемого уровня.
Категории
Коды категорий (facility) syslog используются для указания типа программы, добавляющего сообщение в лог RFC 5424.
| Код категории | Ключевое слово | Описание | Информация |
|---|---|---|---|
| 0 | kern | Сообщения ядра | |
| 1 | user | Сообщения программного обеспечения пользователя | |
| 2 | Почтовая система | Архаический POSIX всё ещё поддерживается и иногда используется (см. mail(1) для получения более подробной информации) | |
| 3 | daemon | Системные службы | Все демоны, включая systemd и его подсистемы |
| 4 | auth | Сообщения безопасности (авторизации) | См. также код 10 |
| 5 | syslog | Собственные сообщения syslogd | Для реализаций syslogd (не используется в systemd, см. код 3) |
| 6 | lpr | Подсистема печати (архаическая подсистема) | |
| 7 | news | Подсистема новостных групп (архаическая подсистема) | |
| 8 | uucp | Подсистема UUCP (архаическая подсистема) | |
| 9 | clock daemon | systemd-timesyncd | |
| 10 | authpriv | Сообщения безопасности (авторизации) | См. также код 4 |
| 11 | ftp | Служба FTP | |
| 12 | — | Подсистема NTP | |
| 13 | — | Журнал аудита | |
| 14 | — | Аварийный журнал | |
| 15 | cron | Служба планирования | |
| 16 | local0 | Локальное использование 0 (local0) | |
| 17 | local1 | Локальное использование 1 (local1) | |
| 18 | local2 | Локальное использование 2 (local2) | |
| 19 | local3 | Локальное использование 3 (local3) | |
| 20 | local4 | Локальное использование 4 (local4) | |
| 21 | local5 | Локальное использование 5 (local5) | |
| 22 | local6 | Локальное использование 6 (local6) | |
| 23 | local7 | Локальное использование 7 (local7) |
Полезные категории для наблюдения: 0, 1, 3, 4, 9, 10, 15.
Фильтрация вывода
journalctl позволяет фильтровать вывод по определённым полям. Если должно быть отображено большое количество сообщений или необходима фильтрация большого промежутка времени, то вывод команды может занять значительное время.
-
Показать сообщения с момента текущей загрузки системы:
# journalctl -b
# journalctl -x
# journalctl --since="2012-10-30 18:17:16"
# journalctl --since "20 min ago"
# journalctl -f
# journalctl /usr/lib/systemd/systemd
# journalctl _PID=1
# journalctl -u man-db.service
$ journalctl --user -u dbus
# journalctl -k
# journalctl -p err..alert
# journalctl SYSLOG_FACILITY=10
# journalctl --file /var/log/journal/*/system.journal -f
Для получения дополнительной информации смотрите страницы справочного руководства journalctl(1) , systemd.journal-fields(7) или пост в блоге Леннарта Пёттеринга.
Совет: По умолчанию journalctl отсекает части строк, которые не вписываются в экран по ширине, хотя иногда перенос строк может оказаться более предпочтительным. Управление этой возможностью производится посредством переменной окружения SYSTEMD_LESS , в которой содержатся опции, передаваемые в less (программу постраничного просмотра, используемую по умолчанию). По умолчанию переменная имеет значение FRSXMK (для получения дополнительной информации смотрите less(1) и journalctl(1) ).
Если убрать опцию S , будет достигнут требуемый результат. Например, запустите journalctl, как показано здесь:
$ SYSTEMD_LESS=FRXMK journalctl
Для использования такого поведения по умолчанию, экспортируйте переменную из файла ~/.bashrc или ~/.zshrc .
Совет: Несмотря на то, что журнал хранится в двоичном формате, содержимое сообщений не изменяется. Это означает, что их можно просматривать при помощи strings, например, для восстановления системы в окружении без systemd. Пример команды:
$ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal | grep -i message
Ограничение размера журнала
Если журнал сохраняется при перезагрузке, его размер по умолчанию ограничен значением в 10% от объема соответствующей файловой системы (и максимально может достигать 4 ГиБ). Например, для каталога /var/log/journal , расположенном на корневом разделе в 20 ГиБ, максимальный размер журналируемых данных составит 2 ГиБ. На разделе же 50 ГиБ журнал сможет занять до 4 ГиБ. Текущие пределы для вашей системы можно узнать из логов systemd-journald :
# journalctl -b -u systemd-journald
Максимальный объем постоянного журнала можно задать вручную, раскомментировав и отредактировав следующий параметр:
/etc/systemd/journald.conf
SystemMaxUse=50M
Также возможно использование конфигурационных сниппетов вместо редактирования глобального файла конфигурации. В таком случае поместите переопределения в разделе [Journal] :
/etc/systemd/journald.conf.d/00-journal-size.conf
[Journal] SystemMaxUse=50M
Перезапустите systemd-journald.service для применения изменений.
Для получения дополнительной информации обратитесь к странице справочного руководства journald.conf(5) .
Ограничение размера для юнита
Отредактируйте файл юнита службы, которую вы хотите настроить (например, sshd), добавив параметр LogNamespace=ssh в раздел [Service] .
Затем создайте файл journald@ssh.conf , скопировав содержимое файла /etc/systemd/journald.conf . Отредактируйте его, задав необходимое значение SystemMaxUse .
Перезапустите юнит, чтобы включилась новая служба журнала systemd-journald@ssh.service . Логи службы из определённого «пространства имён» можно увидеть командой journalctl —namespace ssh .
Очистка файлов журнала вручную
Файлы журнала можно удалить из директории /var/log/journal/ , к примеру, с помощью rm или journalctl для удаления части журналов по определённым критериям. Например:
-
Удалять заархивированные файлы журнала, пока занимаемое ими место не составит менее 100 МиБ:
# journalctl --vacuum-size=100M
# journalctl --vacuum-time=2weeks
Для получения дополнительной информации, обратитесь к journalctl(1) .
Journald вместе с syslog
Совместимость с классической реализацией syslog можно обеспечить, перенаправляя все сообщения systemd через сокет /run/systemd/journal/syslog . Для работы демона syslog с журналом, следует привязать его к данному сокету вместо /dev/log (официальное сообщение).
Для перенаправления данных в сокет, в journald.conf по умолчанию задан параметр ForwardToSyslog=no , чтобы избежать перегрузки на систему, так как rsyslog или syslog-ng самостоятельно получают сообщения из журнала.
Смотрите Syslog-ng#Overview и Syslog-ng#syslog-ng and systemd journal или rsyslog для получения подробной информации о конфигурировании.
Перенаправление журнала в /dev/tty12
Создайте drop-in каталог /etc/systemd/journald.conf.d и файл fw-tty12.conf в нём со следующим содержимым:
/etc/systemd/journald.conf.d/fw-tty12.conf
[Journal] ForwardToConsole=yes TTYPath=/dev/tty12 MaxLevelConsole=info
Затем перезапустите службу systemd-journald .
Выбор журнала для просмотра
Иногда необходимо проверить логи другой системы, например, загружаясь с работоспособной системы для восстановления неисправной. В таком случае примонтируйте диск, к примеру, в /mnt и укажите путь журнала с помощью флага -D / —directory следующим образом:
# journalctl -D /mnt/var/log/journal -e
Доступ к журналу как пользователь
По умолчанию обычные пользователи могут читать только свой собственный пользовательский журнал. Чтобы дать доступ на чтение системного журнала обычному пользователю, добавьте его в группу systemd-journal . Для групп adm и wheel также предоставляется доступ на чтение.
# Использование системных команд systemctl и journalctl
В этой инструкции мы рассмотрим две системные команды, которые нужны для полноценного администрирования на Linux. Дополнительные возможности этих команд позволяют собрать общую информацию о работе сервера и установленных приложений, не используя при этом каких-то сложных инструментов.
Для начала работы нам понадобится:
- подготовленный к работе сервер под управлением Ubuntu. Мы будем рассматривать работу именно на Ubuntu, но общий синтаксис и принцип работы команды распространяются также на Debian и CentOS.
- установленный веб-сервер, например, Nginx. На самом деле обе команды универсальны, использовать Nginx мы будем исключительно в качестве образца для исследования.
# Systemctl
Начнём изучение с команды systemctl . Она предназначена для прямой работы с приложениями. С помощью базовых функций этой команды можно запустить приложение:
sudo systemctl start app sudo systemctl stop app Добавить его в автозагрузку:
sudo systemctl enable app sudo systemctl disable app Важно помнить, что команда systemctl выполняется от имени администратора, поэтому не забывайте указывать префикс sudo .
Также при работе с командой systemctl можно не указывать .service расширение после названия приложения — команда сама проверяет доступность приложений в списке сервисов и выполняет команды в соответствии с ним. Это упрощает синтаксис команды.
# restart vs reload
Для перезапуска приложений у systemctl есть две опции: restart и reload . Синтаксис команды для запуска этих функций стандартный:
sudo systemctl restart app sudo systemctl reload app Основное различие этих функций — во взаимодействии с приложениями. Если restart полностью останавливает приложение и запускает его заново, то reload просто позволяет приложению перечитать конфигурационный файл, с которым оно работает, без полного перезапуска.
# Статус
Одна из основных функций для проверки работы приложений — status :
sudo systemctl status nginx # Output ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/etc/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2022-03-30 08:01:48 +05; 5h 12min ago Docs: man:nginx(8) Process: 354 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 370 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 383 (nginx) Tasks: 3 (limit: 19660) Memory: 11.3M CGroup: /system.slice/nginx.service ├─383 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; ├─384 nginx: worker process └─385 nginx: worker process Mar 24 10:19:27 host systemd[1]: Stopping A high performance web server and a reverse proxy server... Mar 24 10:19:28 host systemd[1]: nginx.service: Succeeded. Эта команда выводит на экран общую информацию о приложении — его статус (Active / Inactive (dead)), добавлено оно в автозагрузку или нет (Enabled / Disabled), PID процесса, количество используемой памяти, зависимости и последние несколько строк лога. Здесь же выводятся системные ошибки при запуске приложения.
Эта информация бывает очень полезной при поиске ошибок и отладке работы приложения.
Вариации этой команды — is-active , is-enabled , is-failed — позволяют проверить одно конкретное состояние приложения без вывода на экран всей остальной информации:
sudo systemctl is-enabled nginx # Output enabled # Просмотр установленных приложений
Также systemctl позволяет проверить список всех установленных на машине приложений:
sudo systemctl list-units # Output UNIT LOAD ACTIVE SUB DESCRIPTION console-getty.service loaded active running Console Getty containerd.service loaded active running containerd container runtime cron.service loaded active running Regular background program processing daemon dbus.service loaded active running D-Bus System Message Bus docker.service loaded active running Docker Application Container Engine fail2ban.service loaded active running Fail2Ban Service getty@tty2.service loaded active running Getty on tty2 ifup@venet0.service loaded active exited ifup for venet0 ifupdown-pre.service loaded active exited Helper to synchronize boot up for ifupdown ifupdown-wait-online.service loaded active exited Wait for network to be configured by ifupdown kibana.service loaded active running Kibana … На экран будет выведена таблица со следующей информацией:
- UNIT — наименование приложения;
- LOAD — правильно ли загружено описание приложения;
- ACTIVE — статус приложения на данный момент;
- SUB — более детальная информация о состоянии приложения;
- DESCRIPTION — описание приложения.
Эта команда также имеет несколько дополнительных функций, позволяющих выводить список только активных в данный момент приложений:
systemctl list-units --all --state=inactive Логичное продолжение этой команды — опция вывода информации об исполняемом файле приложения:
systemctl cat nginx.service Правильное название сервиса, который нужно указать в данной команде, можно взять из списка, выведенного командой systemctl list-units .
Зависимости выбранного сервиса можно посмотреть командой list-dependencies :
sudo systemctl list-dependencies nginx.service nginx.service ● ├─system.slice ● └─sysinit.target ● ├─apparmor.service ● ├─dev-hugepages.mount ● ├─dev-mqueue.mount ● ├─kmod-static-nodes.service ● ├─proc-sys-fs-binfmt_misc.automount ● ├─proc-sys-fs-binfmt_misc.mount ● ├─sys-fs-fuse-connections.mount ● ├─sys-kernel-config.mount ● ├─sys-kernel-debug.mount ● ├─sys-kernel-tracing.mount ● ├─systemd-ask-password-console.path ● ├─systemd-binfmt.service ● ├─systemd-boot-system-token.service ● ├─systemd-hwdb-update.service ● ├─systemd-journal-flush.service … Полное описание сервиса можно вызвать командой:
sudo systemctl show nginx.service # Output Type=forking Restart=no PIDFile=/run/nginx.pid NotifyAccess=none RestartUSec=100ms TimeoutStartUSec=1min 30s TimeoutStopUSec=5s TimeoutAbortUSec=5s RuntimeMaxUSec=infinity WatchdogUSec=0 WatchdogTimestampMonotonic=0 RootDirectoryStartOnly=no … # Маскировка сервиса
Иногда в работе нужно временно исключить из работы один сервис — запретить автоматический доступ к нему и не перезапускать его при перезагрузке системы. Это можно сделать с помощью команды mask :
sudo systemctl mask nginx.service После этого при попытке запуска сервиса можно будет увидеть сообщение:
# Output Failed to start nginx.service: Unit nginx.service is masked. И в общем списке приложений напротив указанного сервиса будет сообщение masked .
Снятие маскировки производится обратной командой:
sudo systemctl unmask nginx.service Это основные инструменты для работы с командой systemctl , позволяющие управлять работой приложений и собирать общую информацию об их работе. Теперь переходим к описанию команды, позволяющей работать с системными логами.
# journalctl
Команда journalctl — один из основных элементов работы с системными логами. Она позволяет не только читать общие системные логи, но и выбирать из них интересующую нас информацию — от временного интервала до конкретного сервиса или приложения.
# Установка локального времени
Начнём работу с логами с установки локального времени на сервере.
Обычно время, установленное на сервере, совпадает с его реальным временем в его часовом поясе. Это бывает неудобно при удалённом администрировании сервера: он подписывает логи своим локальным временем, которое может отличаться от времени администратора. Установим своё время на сервере.
timedatectl Она выведет на экран локальное время, установленное на сервере, UTC-время и укажет часовой пояс, выбранный на сервере. Чтобы изменить время на сервере, нужно указать часовой пояс, время которого будет считаться актуальным. Для этого выведем на экран список всех доступных часовых поясов:
timedatectl list-timezones Выберем из списка нужный и установим его:
sudo timedatectl set-timezone zone_name После этого командой timedatectl можно проверить, установилось ли нужное нам время, и переходить непосредственно к чтению логов.
# Работа с логами
Введите общую команду:
journalctl Она выведет в консоль все логи событий сервера. Будьте внимательны — их может быть очень много.
Чтобы сократить число таких строк, можно добавить флаг -b к основной команде, тогда будут показаны логи только с момента последней перезагрузки сервера. Но даже в этом случае, если сервер нагружен и имеет большой аптайм, список может быть очень длинным.
# Сортировка по времени
Чтобы прочитать логи в определённом временном промежутке, используются флаги —before и —since , после которых указывается время в формате YYYY-MM-DD HH:MM:SS . Также эти флаги можно использовать совместно, чтобы выводить на экран события из определённого временного окна:
journalctl --since "2022-01-01" --until "2022-01-02 12:00" Также эта команда поддерживает более свободный формат указания времени. Например, логи со вчерашнего дня:
sudo journalctl --since yesterday А вот так выглядит указание на то, что временное окно логов нужно закончить час назад:
journalctl --since 12:00 --until "1 hour ago" # Выбор логов конкретного сервиса
Один из наиболее популярных и полезных инструментов при работе с командой journalctl — вывод логов определённого сервиса или приложения. Для этого используется флаг -u , после которого указывается наименование интересующего нас сервиса или приложения. В частности вывод логов SSH-подключений выглядит так:
journalctl -u ssh Этот флаг также сочетается с флагами времени:
journalctl -u ssh --since yesterday Он может сочетаться и с командами на ограничение выводимых строк. Например, можно вывести в консоль последние 20 позиций из логов ssh-подключений:
journalctl -u ssh |tail -20 Посмотреть последние события в логах вне зависимости от сервиса можно с помощью ключа -n , после которого нужно указать количество последних событий:
journalctl -n 20 # Логи и дисковое пространство
В зависимости от загруженности сервера его логи могут занимать очень много места. Команда journalctl позволяет контролировать количество дискового пространства, отведённого для записи логов. Контроль можно осуществлять как по общему занимаемому пространству, так и по глубине времени хранения событий сервера.
journalctl --disk-usage Она выведет в консоль сведения о занимаемом дисковом пространстве в данный момент:
#Output Archived and active journals take up 16.0M in the file system. Далее введите следующую команду:
sudo journalctl --vacuum-size= С её помощью вы можете установить максимально допустимый объём дискового пространства, занимаемый логами. Если в данный момент журнал превышает указанное значение, то все старые записи, выходящие за пределы указанного объёма, будут удалены.
Аналогично работает и эта команда:
sudo journalctl --vacuum-time= Различие в том, что здесь в качестве значения указывается системное время, за которое нужно хранить журналы событий.
Мы описали принципы работы двух глобальных системных команд, которые позволяют собирать большое количество информации о системе и управлять работой приложений. Эти команды и их дополнительные возможности будут очень полезны в повседневной работе с серверами. В частности, чтение логов SSH-подключения может указать на попытки брутфорс-атак на ваш сервер.
© Джино, 2003–2022. «Джино» является зарегистрированным товарным знаком.
Лицензия на телематические услуги связи №150549 от 09.03.2017.
Отключение systemd-journald
Это основное, а дополнительно вы можете проделать такие манипуляции
/etc/systemd/system.conf
Параметр LogLevel=. привести к LogLevel=err
/etc/systemd/coredump.conf
Параметр Storage=. привести к Storage=none
Почему я отключаю логи? Может потамучто я их включаю когда действительно нужно. А если их оставить, то они разьедаются, там по умолчанию стоит размер логов 10% жесткого диска, через продолжительное время пользования systemd-journal (flush) может разьестся до 10-20-30 сек и более. Ограничение тоже вариант, но эфект тотже, накопится.