Главная » Linux

Logger linux что это

Содержание
  1. Linux logger Command Usage Tutorial with Examples
  2. logger Help and Usage Information
  3. logger Command Syntax
  4. Linux Syslog
  5. Print Logs From Syslog
  6. Add Log To Syslog File
  7. Specify Log Priority or Facility
  8. Specify Remote Syslog Server IP Address
  9. Use TCP As Syslog Protocol
  10. Specify Remote Syslog Server Port Number
  11. Redirect Command Output As Log
  12. Log Specified File
  13. Set or Limit Log Size
  14. Ignore Blank or Empty Lines
  15. bash + logger варанты применения
  16. Логи в Linux часть 1. rsyslog, journald и logrotate
  17. Понимание логирования
  18. Понимание ролей rsyslogd и journald
  19. Чтение лог-файлов
  20. Понимание содержимого лог-файла
  21. Команда logger
  22. Настройка rsyslogd
  23. Секции rsyslog.conf
  24. Объекты, приоритеты, и места назначения
  25. Ротация лог-файлов
  26. Работаем с journald
  27. Использование journalctl для поиска событий
  28. Сохранение журнала systemd

Linux logger Command Usage Tutorial with Examples

logger is a command-line tool used in Linux and Unix operating systems in order to add logs to the local /var/log/syslog file or remote Syslog server. logger provides different options for adding logs like setting priority, specifying a remote system or explicitly defining the Syslog port.

logger Help and Usage Information

logger command is installed by default in most of the Linux distributions. So there is no need to install it explicitly. We can print the help and usage information with the -h option like below. The most used options of the logger command will be listed with some description.

logger Help and Usage Information

Alternatively for more detailed help and usage information we can look and use the man page of the logger command like below.

logger Command Man Page

logger Command Syntax

logger command has simple syntax where first options provided and then the log or message we want to send Syslog.

  • `OPTIONS` are single or more options to set some attributes like remote server, port, log facility etc.
  • `LOG` is the log message we want to add or send. Surrounding with double quotes will make is more reliable.

Linux Syslog

Syslog mechanism is an important part of the Linux logging. Most of the Linux distributions like Ubuntu, Debian, CentOS, Mint, RedHat, Suse stores the log files under the /var/log directory. There are different types of logs under this directory like auth, MySQL, apache, etc. Syslog is a generic log file and the system used to store logs related to the system, services, etc. The syslog file can be viewed with the tail command like below.

Linux Syslog

Before starting to add a log to the syslog file printing the current syslog file will be very beneficial. We can use different commands to print the syslog file. tail is a command used to print the last 10 lines of the given file. Alternatively, we can provide the line count we want to print explicitly. In the following example, we will print 30 lines from the /var/log/syslog . We will use the -n option in order to specify the line count.

Add Log To Syslog File

Let’s start with a simple example of the logger command. We will just add a single line to the syslog file without providing any option to the logger command. In the following example, we will add the line “This is just a simple log line” to syslog file. Then we will list by using the tail command.

We can see that the log is added to the end of the file which is listed in the bottom. There is also some information about the log like below.

  • `Feb 26 01:20:47` is the time stamp or date information about the log when it is added to the syslog file.
  • `poftut-com` is the name of the system.
  • `ismail` is the user or logger name.

Specify Log Priority or Facility

Generally, logs are prioritized by the log creating resources. This also called a facility used to categorize the logs. We can provide priority or facility by using the -p or —priority long-form option. If we do not provide the priority of facility the default one is user.notice . In the following example, we will set the lof priority as local3.info .

Specify Remote Syslog Server IP Address

By default, the logger command will put the given logline into the local system /var/log/syslog file. But this is not the case always. In enterprise environments, the logs should be collected and managed in a central log server. We can use the logger command in order to send the given log into the remote server by providing the IP address or hostname. We will use the -n or —server option to send the remote log server.

Use TCP As Syslog Protocol

Syslog uses the UDP protocol by default. UDP provides faster, low resource and easy transmission of log files. But UDP do not provide complete reliability where TCP comes in. We can change the default transmission protocol UDP into TCP by using the -T or —tcp option.

Specify Remote Syslog Server Port Number

When sending a log from the local to the remote system the default port of the syslog is 514 for both UDP and TCP protocols. We can change the port number explicitly by using the -P or —port option by providing the port number.

Redirect Command Output As Log

Linux provides a lot of tools that log their actions precisely. We can use logger command in order to send these commands output as a log. e will just use the bash shell backticks to surround command. Below we will log the command who into the syslog.

Redirect Command Output As Log

The last line of the syslog provides the output of the who command which contains username, console number, and date of the currently logged in user.

Log Specified File

We can put a text files contents line by line into the syslog file. We will use the -f option and provide the file we want to log. In this example, we will log the file named hostnames .

Set or Limit Log Size

Logs are used to create simple information. So when there are some lines with a lot of data they should be translated or set limit. We can set a limit for the character count of the log lines by using the —size option and the character count we want to set. In the following example, we will set the count or limit as 10.

Читайте также:  Cms client для windows 10

Set or Limit Log Size

Ignore Blank or Empty Lines

While reading log lines from a file there may be some blank or empty lines. Logging empty or blank lines are not efficient so we can ignore the blank or empty lines by using the -e option like below.

Источник

bash + logger варанты применения

Повседневные задачи администрирования Linux требуют автоматизации. Как правило, автоматизация сводится к написанию bash скриптов и их «ротации по крону», либо выполнении вручную, в зависимости от задачи. В этой заметке собраны часто встречающиеся практики логирования bash скриптов. Целевая аудитория — системные администраторы linux.

Самый простой и очевидный способ сохранить вывод скрипта это просто перенаправить его в файл.

На самом деле, нужно добавить к выводу STDERR, потому, как сообщения об ошибках пишутся именно в него:

Это считается нормальной практикой и обычно удовлетворяет большую часть системных администраторов. Но если серверов несколько(десятков, сотен), и логирование централизованно, удобнее использовать logger. Напомню, что logger это утилита, которая отправляет сообщения в syslog.

Плюсы такого подхода в том, что можно перенаправлять вывод не только bash скриптов.

Минусы — невозможно отделить сообщения об ошибках от других информационных сообщений, так как в этом примере вывод слеплен в один поток и все это попадает в syslog с приоритетом user.notice(приоритет по умолчанию).

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

В этом варианте логируется только STDERR (STDOUT перенаправляется в /dev/null) с приоритетом error. Также сообщения помечаются тегом с названием скрипта. Все это может упростить поиск и устранения неисправностей в работе скриптов.

Минусом этого подхода является то, что мы теряем STDOUT. Чтобы решить эту проблему можно использовать перенаправление потоков вывода непосредственно внутри скрипта.

Этот пример иллюстрирует как можно перенаправить STDOUT и STDERR независимо друг от друга. К сожалению, этот способ порождает неожиданную проблему: сообщения из разных потоков могут попадать в syslog не в том порядке, в котором были отправлены. Такое поведение связано с тем, что потоки обрабатываются как два независимых друг от друга процесса. Не смотря на это, способ часто применяется для логирования скриптов, запускаемых cron.

Но иногда требуется запускать скрипт вручную, и в этом случае не всегда удобно следить за его работой в syslog.

В этом примере tee копирует «входящий» поток в logger и обратно — в STDOUT(поведение по умолчанию), а во втором случае в STDERR. Таким образом мы получаем логирование в syslog + вывод на консоль во время выполнения, что бывает полезно для скриптов, запускаемых вручную.

Логи в syslog — это просто.
Логи в syslog — это полезно, особенно если логирование централизованно. При параллельном перенаправленнии потоков вывода — следует помнить о возможном нарушении порядка следования сообщений.

Источник

Логи в Linux часть 1. rsyslog, journald и logrotate

Понимание логирования

Понимание ролей rsyslogd и journald

journald (который реализуется демоном systemd-journald) предоставляет усовершенствованную систему управления логами. journald собирает сообщения из ядра, всей процедуры загрузки и сервисов и записывает эти сообщения в журнал событий. Этот журнал событий хранится в двоичном формате, и его можно запросить с помощью команды journalctl.

Поскольку журнал, который пишет journald, не является постоянным между перезагрузками, сообщения также перенаправляются в службу rsyslogd. rsyslogd записывает сообщения в разные файлы в каталоге /var/log.

rsyslogd предлагает функции, которых нет в journald, такие как централизованное ведение журнала и фильтрация сообщений с использованием модулей. В текущем состоянии journald не является заменой rsyslogd; это просто еще один способ регистрации информации. journald тесно интегрирован с systemd и поэтому регистрирует всё, что делает ваш сервер. rsyslogd добавляет к нему некоторые сервисы. В частности, он заботится о записи данных журнала в определенные файлы (которые будут постоянными между перезагрузками) и позволяет настраивать удаленные журналы и серверы журналов.

Чтобы получить больше информации о том, что происходит на машине, администраторы должны использовать три подхода:

  • Файлы в /var/log, которые пишутся rsyslogd, должны контролироваться.
  • Команда journalctl может использоваться для получения более подробной информации из журнала.
  • Для краткого обзора последних значимых событий, которые были зарегистрированы модулями systemd через journald, администраторы могут использовать команду systemctl status . Эта команда показывает состояние сервисов, а также последние пару строк, которые были логированы. В листинге 1 показан пример, в котором эта команда четко указывает, что пошло не так при запуске сервиса.

Листинг 1

Чтение лог-файлов

Помимо сообщений, которые записываются journald и которые можно прочитать с помощью команды journalctl, в системе Linux вы также найдете различные лог-файлы в каталоге /var/log. Эти файлы могут быть прочитаны, например, с помощью less.

Точное количество файлов в каталоге /var/log будет меняться в зависимости от конфигурации сервера и сервисов, работающих на этом сервере. Однако некоторые файлы существуют в большинстве случаев, и, как администратор, вы должны знать, какие это файлы и какое содержимое можно ожидать в этих файлах.

В таблице 1 представлен обзор некоторых стандартных файлов, созданных в этом каталоге.

Таблица 1

log-файл
/var/log/messages

Наиболее часто используемый файл журнала, это общий файл журнала, в который записывается большинство сообщений.

/var/log/dmesg
/var/log/secure

Содержит сообщения, связанные с аутентификацией.

/var/log/boot.log

Сообщения, связанные с запуском системы.

/var/log/audit/audit.log

Содержит сообщения аудита. SELinux пишет в этот файл.

/var/log/maillog
/var/log/samba

Предоставляет файлы журналов для сервиса Samba. Обратите внимание, что по умолчанию Samba не управляется через rsyslog, а записывается непосредственно в каталог /var/log.

/var/log/sssd

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

/var/log/cups

Содержит сообщения, сгенерированные службой печати CUPS.

/var/log/httpd/

Каталог, содержащий лог-файлы, которые записываются веб-сервером Apache. Обратите внимание, что Apache пишет сообщения в эти файлы напрямую, а не через rsyslog.

Понимание содержимого лог-файла

Как администратор, вы должны уметь интерпретировать содержимое лог-файлов. Например, в листинге 2 показан частичный контент из файла /var/log/messages.

Листинг 2
Как видно из листинга 2, каждая записываемая строка имеет определенные элементы:

  • Дата и время: каждое сообщение начинается с отметки времени. В целях фильтрации метка времени записывается как военное время.
  • Хост: хост, с которого отправлено сообщение. Это важно, потому что rsyslogd также может быть настроен для обработки удаленных логов.
  • Имя службы или процесса: имя сервиса или процесса, сгенерировавшего сообщение.
  • Содержимое сообщения: содержимое сообщения, которое содержит точное сообщение, которое было зарегистрировано.

Чтобы прочитать содержимое лог-файла, вы можете использовать, например less, или вы можете в реальном времени наблюдать за тем, что там происходит с помощью команды tail -f. Например: tail -f /var/log/messages.

Команда logger

Большинство сервисов самостоятельно записывают информацию в лог-файлы. Команда logger позволяет пользователям записывать сообщения в rsyslog из командной строки. Использовать эту команду просто. Просто введите logger, и затем сообщение, которое вы хотите записать в логи. Таким образом, утилита logger предлагает удобное решение для написания сообщений из скриптов. Это позволит вам записывать скрипт в syslog, если что-то пойдёт не так.

При использовании logger вы также можете указать приоритет и что вы хотите логировать. Команда logger -p kern.err my_message записывает my_message в объект kern, например, используя приоритет error. Эта опция позволит проверить работу конкретных rsyslog объектов.

Настройка rsyslogd

Чтобы убедиться, что информация, которая должна быть залогирована, записана в то место, где вы хотите ее найти, вы можете настроить сервис rsyslogd в файле /etc/rsyslog.conf. В этом файле вы найдете различные разделы, которые позволяют указать, где и как должна быть записана информация.

Секции rsyslog.conf

Файл rsyslog.conf используется для указания того, что должно быть зарегистрировано и где это должно быть зарегистрировано. Для этого вы найдете различные разделы в файле конфигурации:

■ #### MODULES ####: rsyslogd является модульным. Модули включены для улучшения поддерживаемых функций в rsyslogd.

■ #### GLOBAL DIRECTIVES ####: Этот раздел используется для указания глобальных параметров, таких как место, где записываются вспомогательные файлы, или формат метки времени по умолчанию.

■ #### RULES ####: Это самая важная часть файла rsyslog.conf. Он содержит правила, которые определяют, какая информация должна быть залогирована и в каком месте.

Объекты, приоритеты, и места назначения

Чтобы указать, какая информация должна логироваться и в каком месте назначения, rsyslogd использует объект (Facility), приоритет (Priority) и место назначения (Destination):

■ Объект определяет категорию информации, которая логируется. Rsyslogd использует фиксированный список объектов, который не может быть расширен. Это связано с обратной совместимостью с устаревшей службой syslog.

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

■ Назначение определяет, куда должно быть записано сообщение. Типичными адресатами являются файлы, но модули rsyslog также могут использоваться в качестве места назначения для дальнейшей обработки через модуль rsyslogd.

В листинге 3 приведен пример раздела RULES в rsyslog.

Листинг 3
В листинге 3 вы можете увидеть, как различные объекты и приоритеты используются для определения местоположений, в которые можно логировать информацию. Доступные объекты и приоритеты являются фиксированными и не могут быть добавлены. Таблица 2 показывает, какие объекты доступны, а таблица 3 показывает список всех приоритетов.

При указании назначения часто используется файл. Если имя файла начинается с дефиса (как -/var/log/maillog), сообщения не будут немедленно переданы в файл, а будут буферизированы для повышения эффективности записи. Файлы устройств также могут быть использованы, как /dev/console. Если используется устройство, сообщения записываются в режиме реального времени на консоль. На современных серверах это не имеет смысла, поскольку администраторы часто входят в систему удаленно и не видят, что происходит на консоли сервера.

Для расширения функциональности rsyslogd могут использоваться модули для дальнейшей обработки сообщений. Если это требуется, имя модуля может быть указано как :имя_модуля:.

Таблица 2

Объект
auth / authpriv

Сообщения, связанные с аутентификацией.
cron

Сообщения, сгенерированные сервисом crond.
daemon

Универсальный объект, который можно использовать для неопределенных демонов.
kern

Сообщения ядра.
lpr

Сообщения, сгенерированные через систему печати.
mail

Сообщения, связанные с электронной почтой.
mark

Специальный объект, который можно использовать для периодической записи маркера.
news

Сообщения, генерируемые системой новостей NNTP.
security

То же, что и auth / authpriv. Не должен больше использоваться.
syslog

Сообщения, генерируемые системой syslog.
user

Сообщения генерируемые в пространстве пользователя.
uucp

Сообщения, сгенерированные устаревшей системой UUCP.
local0-7

Резервные объекты, которые необходимы для использования тех объектов, которые отсутствуют в этой таблице.

Объекты syslog были определены в 1980-х годах, и для обеспечения обратной совместимости никакие новые объекты не могут быть добавлены. В результате все еще существуют некоторые объекты, которые в основном больше не используются, а некоторые сервисы, которые стали актуальными на более позднем этапе, не имеют своего собственного объекта. Как решение, два конкретных типа объекта могут быть использованы. Объект daemon — это общий объект, который может использоваться любым демоном. И могут быть использованы объекты local0 — local7.

Если есть сервисы, которые не имеют своих собственных объектов rsyslogd, которым необходимо в любом случае записывать сообщения в определенный лог-файл, эти сервисы можно настроить для использования любого из объектов от local0 до local7. Затем вы должны настроить сервисы для использования этих объектов. Процедура, которой вы пользуетесь, зависит от используемого вами сервиса. Затем вам нужно добавить правило в файл rsyslog.conf, чтобы отправлять сообщения, поступающие через этот объект, в определенный флог-файл. Упражнение 2 показывает, как вы можете это сделать.

Чтобы определить, какие типы сообщений должны логироваться, в строках rsyslog.conf могут использоваться разные уровни серьезности. Эти серьезности являются syslog-приоритетами. В таблице 3 представлен обзор доступных приоритетов в порядке возрастания.

Таблица 3

Приоритет

Используется для
debug

Отладочные сообщения, которые дадут как можно больше информации о работе сервиса.
info

Информационные сообщения о нормальной работе сервиса.
notice

Используется для информационных сообщений об элементах, которые позже могут стать проблемой.
warning / warn

Что-то не оптимальное, но ошибки пока нет.
err /error

Произошла некритическая ошибка.
crit

Произошла критическая ошибка.
alert

Используется, когда сервис перестал быть доступен.
emerg / panic

Сообщение генерируется, когда доступность сервиса прекращается.

Когда используется определенный приоритет, все сообщения с этим приоритетом и выше логируются в соответствии со спецификациями, используемыми в этом конкретном правиле. Если вам необходимо детально настроить логирование, когда сообщения с разными приоритетами отправляются в разные файлы, вы можете указать приоритет со знаком равенства (=) перед ним, как в следующем файле конфигурации, который будет отправлять все отладочные сообщения cron в файл с именем /var/log/cron.debug. Обратите внимание на использование дефиса (-) перед именем файла, который гарантирует, что сообщения буферизуются и не записываются немедленно на диск (что хорошо для производительности диска).

Рассмотрим следующую строку, где все сообщения cron только с приоритетом отладки записываются в определенный файл. Обратите внимание на — перед строкой, который буферизует записи, чтобы информация логировалась более эффективным способом:

Упражнение 2. Изменение правил в rsyslog.conf
В этом упражнении вы узнаете, как изменить rsyslog.conf. Вы настроите сервис Apache для логирования сообщений через syslog и создадите правило, которое записывает сообщения отладки в определенный файл.

1. По умолчанию сервис Apache не логируется через rsyslog, но ведет собственное логирование. Вы измените это. Для начала установите Apache командой yum install -y httpd.

2. После установки Apache откройте его файл конфигурации /etc/http/conf/httpd.conf и добавьте в него следующую строку:
3. Введите systemctl restart httpd.

4. Теперь создайте строку в файле rsyslog.conf, которая будет отправлять все сообщения, которые он получает для объекта local1 (который теперь используется сервисом httpd), в файл /var/log/httpd-error.log. Для этого включите следующую строку:
5. Скажите rsyslogd перезагрузить его конфигурацию, выполнив команду systemctl restart httpd.

6. Все сообщения об ошибках Apache теперь будут записываться в файл httpd-error.log.

7. В браузере Firefox перейдите по адресу http://localhost/nowhere. Так как страницы, к которой вы пытаетесь получить доступ, не существует, она будет записана в журнал ошибок Apache.

8. Теперь давайте создадим snap-in файл, который также записывает сообщения отладки в определенный файл. Для этого введите echo «*.debug /var/log/messages/messages-debug» > /etc/rsyslogd/debug.conf.

9. Снова перезапустите rsyslogd с помощью systemctl restart rsyslogd.

10. Выполните tail -f /var/log/messages-debug, чтобы открыть трассировку для вновь созданного файла.

11. Введите logger -p daemon.debug «Daemon Debug Message». Вы увидите сообщение отладки.

Ротация лог-файлов

Чтобы syslog сообщения не заполняли вашу систему, сообщения можно ротировать. Это означает, что когда будет достигнут определенный порог,
старый лог-файл закроется и откроется новый. Утилита logrotate периодически запускается через сервис crond, чтобы позаботиться о ротации лог-файлов.

Когда лог-файл ротируется, старый файл копируется в файл с датой ротации. Таким образом, если /var/log/messages ротируется 3 ноября 2019 года, то ротируемое имя файла будет /var/log/messages-20191103. По умолчанию в системе хранятся четыре старых лог-файлов. Файлы старше этого периода удаляются из системы автоматически.

Настройки по умолчанию для ротации логов хранятся в файле /etc/logrotate.conf

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

Если для определенных файлов требуются определенные настройки, вы можете создать файл конфигурации для этого файла в /etc/logrotate.d. Настройки для этого файла перезаписывают настройки по умолчанию в /etc/logrotate.conf.

Работаем с journald

Сервис systemd-journald хранит лог-сообщения в журнале в двоичном виде, который хранится в файле /run/log/journal. Этот файл можно просмотреть с помощью команды journalctl.

Использование journalctl для поиска событий

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

Поскольку журнал записывается с момента загрузки сервера, в нем отображаются сообщения журнала, связанные с загрузкой. Если вы хотите просмотреть последние сообщения, которые были зарегистрированы, вы можете использовать journalctl -f, который показывает последние строки сообщений, в которые автоматически добавляются новые строки журнала.

Вы также можете ввести journalctl и нажать кнопку G (заглавная буква) , чтобы перейти к концу журнала. Также обратите внимание, что в выводе journalctl работают параметры поиска / и ?. В листинге 4 показан частичный вывод journalctl.

Листинг 4
Что делает journalctl гибкой командой, так это то, что ее многочисленные опции фильтрации позволяют вам показать именно то, что вам нужно. Упражнение 3 показывает некоторые из наиболее интересных вариантов.

Упражнение 3
В этом упражнении вы узнаете, как работать с различными оциями journalctl.

1. Введите journalctl. Вы увидите содержимое журнала с момента последнего запуска сервера, начиная с начала журнала. Содержимое отображается в меньшем количестве, поэтому вы можете использовать, например, less для просмотра файла.

2. Введите q, чтобы выйти из пейджера. Теперь введите journalctl —no-pager. Эта опция показывает содержимое журнала без использования пейджера.

3. Введите journalctl -f. Эта опция открывает режим просмотра в реальном времени, который позволяет видеть новые сообщения в режиме реального времени.

4. Введите journalctl и дважды нажмите клавишу Tab. Будут показаны конкретные опции, которые можно использовать для фильтрации. Выполните, например, journalctl _UID=0.

5. Введите journalctl -n 20. Опция -n 20 отображает последние 20 строк журнала (так же, как tail -n 20).

6. Теперь введите journalctl -p err. Эта команда показывает только ошибки.

7. Если вы хотите просмотреть сообщения журнала, записанные за определенный период времени, вы можете использовать команды —since и —until. Оба варианта принимают параметр времени в формате ГГГГ-ММ-ДД чч:мм:сс. Кроме того, вы можете использовать yesterday, today и tomorrow в качестве опций. Итак, введите journalctl —since yesterday, чтобы показать все сообщения, которые были написаны со вчерашнего дня.

8. journalctl позволяет комбинировать различные варианты. Итак, если вы хотите показать все сообщения с приоритом err, которые были написаны со вчерашнего дня, то используйте journalctl —since yesterday -p err.

9. Если вам нужно как можно больше подробностей, используйте journalctl -o verbose.

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

Сохранение журнала systemd

По умолчанию журнал хранится в файле /run/log/journal. Весь каталог /run используется только для информации о текущем состоянии процесса, что означает, что журнал очищается при перезагрузке системы. Чтобы сделать журнал постоянным между перезагрузками системы, вы должны убедиться, что существует каталог /var/log/journal.

Даже если журнал записывается в постоянный файл в /var/log/journal, это не означает, что журнал сохраняется вечно. Журнал имеет встроенную ротацию логов, которая будет использоваться ежемесячно. Кроме того, максимальный размер журнала ограничен 10% размера файловой системы, и он также прекратит расти, если менее 15% файловой системы все еще свободно. Если это произойдет, самые старые сообщения из журнала автоматически удаляются, чтобы освободить место для новых сообщений. Чтобы изменить эти настройки, вы можете изменить файл /etc/systemd/journald.conf. Вы увидите, что в этом файле также можно установить некоторые другие параметры (Листинг 6).

Сделать журнал постоянным не сложно. Упражнение 4 показывает, как это сделать.

Упражнение 4
В этом упражнении вы узнаете, как сделать журнал journald постоянным.

1. Войдите под root и введите mkdir /var/log/journal.

2. Прежде чем journald сможет записать журнал в этот каталог, вы должны установить владельца. Введите chown root:systemd-journal /var/log/journal, а затем chmod 2755 /var/log/journal.

3. Затем вы можете либо перезагрузить систему (недостаточно перезапустить службу systemd-journald), либо воспользоваться командой killall -USR1 systemd-journald.

4. Журнал systemd теперь сохраняется при перезагрузках. Если вы хотите просмотреть сообщения журнала с момента последней перезагрузки, используйте journalctl -b.

Источник

Читайте также:  Драйверы устройств для linux 3 е издание
Оцените статью
© 2024 Советы по настройке компьютера