Manjaro

Difference between revisions of "Limit the size of .log files & the journal/ru"

(Created page with "= Введение =")
Tags: Mobile web edit Mobile edit
 
(Updating to match new version of source page)
 
(136 intermediate revisions by one other user not shown)
Line 3: Line 3:
= Введение =
= Введение =


  Note: 18-Feb-17: Updated the Journal section
  {{BoxInfo|Примечание|18-фев-17: Обновлен раздел "Журнал" и создана страница поддержки на форуме.
      & created a Support page in the forum.
12-фев-14: Улучшен раздел "Журнал".  
      12-Feb-14: Improved Journal section.  
24-мар-14: Приведено в порядок содержание страницы и добавлено содержание следующего раздела.}}
      24-Mar-14: Tidied content of page &
      added content to the next section.


Log files & the systemd journal do the same thing in different ways. They keep a record of everything that happens on your computer system. This makes it possible to understand what is going right & what is going wrong. As an example, if your system had been infiltrated by an ssh attack, this could be verified in the log/journal. So these log files are good for more than tracking troublesome hardware, or driver problems, badly written network manager code or the plethora of other problems that the complex & dynamic GNU/Linux system has to deal with.  
Файлы журналов и журнал systemd делают одно и то же, но по-разному. Они ведут запись всего, что происходит в вашей системе. Это позволяет понять что работает правильно, а что - нет. Например, если ваша система подверглась ssh-атаке - это может быть отобажено в логе/журнале. Таким образом, эти журналы полезны не только для отслеживания проблем с оборудованием, драйверами, плохо написанным кодом сетевого менеджера или множества других проблем, с которыми приходится сталкиваться сложной и динамичной системе GNU/Linux.  


These logs are an absolute blessing, as not all systems have them, & those server administrators who do have them sould be very grateful, as they can be the bread & butter of what they do.  
Эти журналы - настоящее спасение, поскольку не все системы имеют их, и те администраторы серверов, у которых они есть, должны быть очень благодарны, поскольку они могут быть хлебом и маслом для их работы.  


Generally, only server administrators have use for logs that go back any length of time. Few users who run distros on their desktop, notebook, netbook and such machines, have need to keep such huge log files or histories going back for many months or even years on their system. They are a waste of space & also makes viewing your log files more cumbersome.  
Как правило, только администраторы серверов используют журналы, хранящиеся в течение длительного времени. Лишь немногие пользователи дистрибутивов на настольных компьютерах, ноутбуках, нетбуках и подобных машинах, нуждаются в хранении таких огромных файлов журналов или историй за многие месяцы или даже годы. Они занимают много места, а также делают просмотр журналов более сложным.  


<br clear="all"/>
<br clear="all"/>


==== The first topic on this page will briefly cover the '''systemd journal''' ====
==== В первой теме на этой странице будет кратко рассмотрен '''журнал systemd''' ====


The systemd journal has taken the place of log files though it will happily run in parallel with the standard type log files. These are still created & maintained by default in Arch & Manjaro. If you delete syslog-ng & all of the /var/log/*log files on reboot you will find that some log files will be automatically created again. On my machine after having deleted syslog-ng & all of the /var/log/*.log files (except for the Xorg.0.log files), my machine now has the following (wtmp & btmp are created on boot by the /etc/logrotate.conf file) contents in my /var/log/ :
Журнал systemd занял место файлов журналов, хотя он прекрасно работает параллельно с файлами журналов стандартного типа. Они по-прежнему создаются и поддерживаются по умолчанию в Arch и Manjaro. Если вы удалите syslog-ng и все файлы /var/log/*log, то при перезагрузке обнаружите что некоторые файлы логов будут созданы снова автоматически. На моей машине после удаления syslog-ng и всех файлов /var/log/*.log (за исключением Xorg.0.log), моя машина теперь имеет следующее содержимое (wtmp и btmp создаются при загрузке файлом /etc/logrotate.conf) в /var/log/:


  journal/
  journal/
Line 33: Line 31:
<br clear="all"/>
<br clear="all"/>


==== The second topic will cover handling log files ====
==== Вторая тема будет посвящена работе с файлами журналов ====


This topic will go into far more depth, covering the use of the '''logrotate''' command, '''logrotate.conf''', the '''/etc/cron.daily cron.weekly cron.monthly cron.yearly''', and some ways to run created scripts, plus a mention of the '''crontab''' method of running a script also. I'll try to make this section accessible to as many people as possible, which means this will be a long page.
Эта тема будет более глубокой - в ней мы рассмотрим использование команды '''logrotate''', '''logrotate.conf''', '''/etc/cron.daily cron.weekly cron.monthly cron.yearly''' и некоторые способы запуска созданных скриптов, а также упомянем метод запуска скрипта '''crontab'''. Я постараюсь сделать этот раздел доступным для как можно большего числа людей, а это означает что страница будет довольно длинная.


<br clear="all"/>
<br clear="all"/>


= The journal & the logs duplicate the same information =
= Журнал и логи дублируют одну и ту же информацию =


You can read the text of the log files in a text editor, or using the '''cat''', '''more''', '''less''' & such commands as you would on any other text file. The journal on the other hand requires the '''journalctl''' command to be able to access its contents. The following is a good way to read the journal:
Вы можете читать текст файлов логов в текстовом редакторе или с помощью команд '''cat''', '''more''', '''less''' и подобных, как и для любого другого текстового файла. Журнал же требует команды '''journalctl''' для доступа к его содержимому. Ниже приведен хороший способ чтения журнала:


  sudo journalctl
  sudo journalctl
Line 47: Line 45:
<br clear="all"/>
<br clear="all"/>


=Read this its important=
=Прочитайте это - это важно=


  Note: '''etc/systemd/journald.conf.d/*.conf'''  
  {{BoxInfo|Примечание|'''/etc/systemd/journald.conf.d/*.conf'''  
  overrides the file '''journald.conf'''
  переопределяет файл '''journald.conf'''}}


'''man journald.conf'''
'''man journald.conf'''


When packages need to customize the configuration, they can install configuration snippets in
Когда пакетам необходимо настроить конфигурацию - они могут установить фрагменты конфигурации в /usr/lib/systemd/*.conf.d/. Файлы в /etc/ зарезервированы для локального администратора, который может использовать эту логику для переопределения конфигурационных файлов, установленных пакетами вендора. Главный конфигурационный файл читается перед любым из каталогов конфигурации и имеет наименьший приоритет; записи в файле в любом каталоге конфигурации переопределяют записи в единственном файле конфигурации. Файлы в подкаталоге конфигурации *.conf.d/ сортируются по имени файла в лексикографическом порядке, независимо от того, в каком из подкаталогов они находятся. Если в нескольких файлах указана одна и та же опция, приоритет имеет запись в файле с самым лексикографически последним именем. Рекомендуется снабжать все имена файлов в этих подкаталогах двузначным числом и тире для упрощения упорядочивания файлов.
/usr/lib/systemd/*.conf.d/. Files in /etc/ are reserved for the local administrator, who may use
this logic to override the configuration files installed by vendor packages. The main configuration
file is read before any of the configuration directories, and has the lowest precedence; entries in
a file in any configuration directory override entries in the single configuration file. Files in
the *.conf.d/ configuration subdirectories are sorted by their filename in lexicographic order,
regardless of which of the subdirectories they reside in. If multiple files specify the same option,
the entry in the file with the lexicographically latest name takes precedence. It is recommended to
prefix all filenames in those subdirectories with a two-digit number and a dash, to simplify the
ordering of the files.


What that means is that you can create configuration files '''.conf''' in the '''/etc/systemd/journald.conf.d/''' directory, with suitable names of your choice. The content of these files take precedence over any other settings or configurations in systemd. Please bear that in mind when you read the following? In my cumbersome way I've tried to make it all too obvious...
Это означает, что вы можете создавать конфигурационные файлы '''.conf''' в каталоге '''/etc/systemd/journald.conf.d/''' с подходящими именами по вашему выбору. Содержимое этих файлов имеет приоритет над любыми другими настройками или конфигурациями в systemd. Пожалуйста, имейте это в виду, когда будете читать следующее. В своей многословной манере я попытался сделать все это слишком очевидным...


<br clear="all"/>
<br clear="all"/>


== How to set a maximum size limit for the journal ==
== Как установить ограничение на максимальный размер журнала ==


There is usually no need to interfere with the maximum size of the journal, as it has been built to monitor the amount of free space on the partition where it exists & will shrink itself by deleting the oldest entries when a shortage of space demands it.
Обычно нет необходимости вмешиваться в максимальный размер журнала, так как он создан для мониторинга количества свободного места на разделе, где он существует, и будет самостоятельно удалять самые старые записи, когда этого потребует нехватка места.


Use your favorite text editor with root privileges, (starting it with '''sudo''' will do the job).
Используйте ваш любимый текстовый редактор с привилегиями root (запустите его с помощью '''sudo''').


  Note: the name '''size'''.conf is user created.
  {{BoxInfo|Примечание|файл '''size'''.conf создается пользователем}}


With your text editor create a file called '''size.conf''' in the following location '''/etc/systemd/journald.conf.d/size.conf''' The following sets the maximum file size to a 50 MB limit for the '''/var/log/journal''' . ''(The SystemMaxUse=250M is for use with logrotate, which is looked at in the 2nd section of this page. Talk to papajoke on the forum if you need help with logrotate & systemd.)''
С помощью текстового редактора создайте файл под названием '''size.conf''' в следующем месте '''/etc/systemd/journald.conf.d/size.conf'''. Следующий файл устанавливает максимальный размер файла в 50 МБ для '''/var/log/journal''' . ''(SystemMaxUse=250M предназначено для использования с logrotate, рассматриваемыми во втором разделе этой страницы. Поговорите с papajoke на форуме если вам нужна помощь с logrotate и systemd.)''


  [Journal]
  [Journal]
Line 83: Line 72:
  SystemMaxFileSize=50M
  SystemMaxFileSize=50M


You can also limit the content of the journal by specifying the level of the data to be added to the journal. This is done by creating & editing the file '''/etc/systemd/journald.conf.d/level.conf'''
Вы также можете ограничить содержимое журнала, указав уровень данных, добавляемых в журнал. Это делается путем создания и редактирования файла '''/etc/systemd/journald.conf.d/level.conf'''.


  Note: the name '''level'''.conf is user created.
  Примечание: файл '''level'''.conf создается пользователем.


  [Journal]
  [Journal]
  # not save all levels but only 0 to 4
  # не сохранять все уровни, а только от 0 до 4
  MaxLevelStore=warning
  MaxLevelStore=warning


<br clear="all"/>
<br clear="all"/>


=The Journalctl command - a quick reference [http://www.freedesktop.org/software/systemd/man/journalctl.html]=
= Команда Journalctl - краткое руководство [http://www.freedesktop.org/software/systemd/man/journalctl.html]=


  Note: Following are few pointers on things
  {{BoxInfo|Примечание|Ниже приведены несколько советов о том, что вы можете сделать, чтобы использование journalctl стало быстрее, проще и эффективнее в вашей системе.}}
you can do to make using journalctl quicker,
easier & more effective, on your system.


==You don't have to use "sudo" with journalctl==
==Вы не должны использовать "sudo" с journalctl==


Add your '''user''' to '''adm''' group. This gives your <user> full use of the '''journalctl''' command. No more need to use sudo.  
Добавьте вашего '''пользователя''' в группу '''adm'''. Это даст вашему <пользователю> полное право использовать команду '''journalctl'''. Больше не нужно использовать sudo.  
Swap "handy" for your username in the following:
Поменяйте "handy" на ваше имя пользователя в следующих строках:
   
   
  # usermod -a -G adm handy
  # usermod -a -G adm handy


==See the whole line of the journalctl output text==
==Посмотреть всю строку вывода journalctl==


You can pipe the output of journalctl to a file or to a text display tool like "More" or "Less", as follows:
Вы можете передать вывод journalctl в файл или в инструмент отображения текста, например, "More" или "Less", следующим образом:
    
    
  $ journalctl -b -p err|less
  $ journalctl -b -p err|less
Doing so, gives you a means of avoiding the truncation of output which some system displays configurations may experience.


===Use a ~/.bashrc alias to make this easy===
Это позволит избежать усечения вывода, которое может наблюдаться в некоторых конфигурациях дисплеев.
 
===Используйте альяс ~/.bashrc чтобы сделать это проще===


I use the following ~/.bashrc alias:
Я использую следующий альяс ~/.bashrc:
   
   
  alias errors="journalctl -b -p err|less"
  alias errors="journalctl -b -p err|less"  
При вводе '''errors''' в терминале, все ошибки или проблемы с момента последней загрузки отправляются (передаются) в инструмент отображения текста в терминале под названием '''Less''', который оборачивает текстовый вывод команды {{ic|journalctl}}. Помимо этого, он делает ошибки более удобочитаемыми для тех, кто будет читать их на форуме!
On entering '''errors''' in the Terminal, all errors or worse since the last boot are sent to (piped) to the Terminal based text display tool called '''Less''' which wraps the text output of the journalctl command. Apart from anything else, it makes the errors more useful for anyone reading them in the forum!


Type '''Q''' (upper or lower case) to close "Less".
Введите {{key press|q}} (в верхнем или нижнем регистре) чтобы закрыть "Less".




=== Access to full journal containing info from the system & users: ===
=== Доступ к полному журналу, содержащему информацию о системе и пользователях: ===


  $ journalctl
  $ journalctl


=== Live view, shows the last 10 lines of the journal & all content as it happens: ===
=== Просмотр в реальном времени - показывает последние 10 строк журнала и все содержимое по мере того как он пополняется: ===


  $ journalctl -f
  $ journalctl -f


== Basic filtering: ==
== Основная фильтрация: ==


=== Shows all output to the journal since the last boot:===
=== Показывает весь вывод в журнал с момента последней загрузки:===


  $ journalctl -b
  $ journalctl -b


=== Shows all output with priority level ERROR & worse, since last boot: ===
=== Показывает весь вывод с уровнем приоритета ERROR и выше с момента последней загрузки: ===


  $ journalctl -b -p err
  $ journalctl -b -p err


Following is the above command with its output sent to a file called '''-ERRORS''' in your ''/home/<user>'' directory. Having the '''-''' at the beginning of the name should cause the file to be shown at the top of the list of files when viewing the contents of your '''~/''' (''/home/<user>'') directory. This command makes it easy to copy the contents of the -ERRORS file, & then paste it to the forum. Doing so allows us to display ALL of the command's output instead of only being able to cut & paste the truncated lines from our terminal:
Ниже приведена команда, вывод которой отправляется в файл с именем '''-ERRORS''' в каталоге '''/home/<user>'''. Наличие символа '''-''' в начале имени должно привести к тому, что файл будет отображаться в самом начале списка файлов при просмотре содержимого вашего каталога '''~/''' (''/home/<user>''). Эта команда позволяет легко скопировать содержимое файла -ERRORS, а затем вставить его на форум. Это дает нам возможность отобразить ВЕСЬ вывод команды, а не только вырезать и вставлять усеченные строки из терминала:


  $ Journalctl -b -p err > -ERRORS
  $ Journalctl -b -p err > -ERRORS


== Filtering based on time: ==
== Фильтрация по времени: ==


=== Since yesterday: ===
=== Со вчерашнего дня: ===


  $ journalctl --since=yesterday
  $ journalctl --since=yesterday


=== Give a specific time period: ===
=== Указать конкретный период времени: ===


  $ journalctl --since=2012-10-15 --until="2011-10-16 23:59:59"
  $ journalctl --since=2012-10-15 --until="2011-10-16 23:59:59"


=== Pick a specific service & time period: ===
=== Выбрать конкретную службу и период времени: ===


  $ journalctl -u httpd --since=00:00 --until=9:30
  $ journalctl -u httpd --since=00:00 --until=9:30


== Point journalctl at specific devices, services, binaries ==
== Указать journalctl на определенные устройства, сервисы, двоичные файлы ==


=== Look at a specific device: ===
=== Просмотр конкретного устройства: ===


  $ journalctl /dev/sdc
  $ journalctl /dev/sdc


=== Check on a binary: ===
=== Проверка бинарного файла: ===


  $ journalctl /usr/sbin/vpnc
  $ journalctl /usr/sbin/vpnc


=== Check on the interlieved output from two specifics: ===
=== Проверка взаимосвязанного вывода двух характеристик: ===


  $ journalctl /usr/sbin/vpnc /usr/sbin/dhclient
  $ journalctl /usr/sbin/vpnc /usr/sbin/dhclient


=== Show all systemd units that have been started in your journal: ===
=== Показать все модули systemd, запущенные в вашем журнале: ===


  $ journalctl -F _SYSTEMD_UNIT
  $ journalctl -F _SYSTEMD_UNIT


You can then interrogate the journal specifying any of those units.
Затем вы можете опросить журнал, указав любой из этих модулей.


== A summation ==
== Резюмируя ==


The Systemd Journal is capable of advanced functions beyond what has been mentioned here. The above is very good food for thought for people that are wondering if they need to be running '''syslog-ng''' or the like that creates most of the '''/var/log/*log''' files on their systems.
Журнал Systemd способен выполнять расширенные функции, выходящие за рамки того, что было упомянуто здесь. Вышеизложенное является очень хорошей пищей для размышлений людям, задающимся вопросом, нужно ли им запускать '''syslog-ng''' или что-то подобное, создающее множество файлов '''/var/log/*log''' в их системах.


By experimenting with the above commands one can make an informed decision for themselves, though as mentioned at the beginning of the Journal section, Arch & therefore Manjaro still run both the new systemd journal & the old style log file system in parallel. So if you find the /var/log/*log files to be redundant & you want to be rid of them, various methods would be effective.
Экспериментируя с приведенными выше командами, можно принять обоснованное решение, хотя, как уже упоминалось в начале раздела "Журнал", Arch и, соответственно, Manjaro все еще работают параллельно с новым журналом systemd и файловой системой журналов старого стиля. Поэтому, если вы считаете файлы /var/log/*log избыточными и хотите избавиться от них - эффективными будут различные методы.


As of this writing I'm running my system with '''syslog-ng''' (& its dependency) deleted. I deleted all of the log files from the /var/log directory (leaving any that are in their own sub-directories), except for Xorg.0.log , Xorg.0.old , lastlog , btmp & wtmp, (pacman.log turned up when pacman was used, depending on what you have installed on your system, you may have applications that create their own logs - which can be turned off - too). (Note: These days I'm systemd free as I've been very happily using the OpenRC init system instead.)
На данный момент я запускаю свою систему с удаленным '''syslog-ng''' (и его зависимостью). Я удалил все файлы журналов из каталога /var/log (оставив тоько находящиеся в собственных подкаталогах), кроме Xorg.0.log, Xorg.0.old, lastlog, btmp и wtmp, (pacman.log появлялся при использовании pacman, в зависимости от того, что у вас установлено в системе, у вас могут быть приложения, создающие свои собственные журналы - которые можно отключить). {{BoxInfo|Примечание|В настоящее время я не использую systemd, так как с удовольствием пользуюсь системой инициализации OpenRC.}}


<br clear="all"/>
<br clear="all"/>


= Managing /var/log/* files =
= Управление файлами /var/log/* =


== Introducing Logrotate & friends ==
== Представляем Logrotate и друзей ==


What is this Logrotate? [http://linux.die.net/man/8/logrotate] logrotate is a powerful tool used to manage the log files created by system processes. It can be instructed to automatically compress, rename in a variety of ways, remove logs, to do all of this & more in a way that maximizes the convenience of logs & conserves your system's resources. An enormous amount of control is available to users including running scripts on your rotated files.  
Что такое Logrotate? [https://www.opennet.ru/man.shtml?topic=logrotate&category=8&russian=0] logrotate - это мощный инструмент, используемый для управления лог-файлами, создаваемыми системными процессами. Его можно настроить на автоматическое сжатие, переименование различными способами, удаление журналов, на выполнение всего этого и многого другого таким образом, чтобы максимально повысить удобство использования журналов и сэкономить ресурсы системы. Пользователям доступно огромное количество средств контроля, включая запуск скриптов на ваших ротируемых файлах.  


A problem I face in trying to make this article about logrotate as simple as possible is that logrotate can be called in so many ways, & these ways are not mutually exclusive.  
Проблема, с которой я столкнулся пытаясь сделать эту статью о logrotate как можно более простой, заключается в том, что logrotate можно вызвать очень многими способами и эти способы не являются взаимоисключающими.  


For example, logrotate can be called to run on a file, or multiple files in any combination or multiple of '''hourly, daily, weekly, monthly & yearly''', via scripts placed in the /etc/ in the already existing directories '''hourly daily weekly monthly''' the '''yearly''' directory can be added if required. '''crontab''' [http://www.adminschoice.com/crontab-quick-reference/] can be used to run logrotate or scripts as complex as a person needs. logrotate can be combined with other tools in anyway that a user can come up with to process these rotated files at any time & frequency.
Например, logrotate может быть вызван для запуска файла или нескольких файлов в любой комбинации или кратности '''ежечасно (hourly), ежедневно (daily), еженедельно (weekly), ежемесячно (monthly) и ежегодно (yearly)''', через скрипты, размещенные в /etc/ в уже существующих каталогах '''hourly daily weekly monthly''' (каталог '''yearly''' может быть добавлен при необходимости). '''crontab''' [https://www.opennet.ru/man.shtml?topic=crontab&category=1&russian=0] можно использовать для запуска logrotate или настолько сложных скриптов, насколько это необходимо. logrotate можно комбинировать с другими инструментами, которые пользователь может придумать для обработки этих ротируемых файлов в любое время и с любой частотой.


<br clear="all"/>
<br clear="all"/>
==== The scope of this article ====
==== Область применения данной статьи ====


That said, much of the power of logrotate is for the benefit of those administering servers & will not be dealt with in the following. Though what we will deal with can be used on more than just our log files. We can use logrotate to backup any other files that we choose. I will expand on this at a later date.
Тем не менее, большая часть возможностей logrotate предназначена для администраторов серверов и не будет рассматриваться ниже. Хотя то, что мы рассмотрим, может быть использовано не только для файлов журналов. Мы можем использовать logrotate для резервного копирования любых других файлов по своему усмотрению. Я расскажу об этом позже.


<br clear="all"/>
<br clear="all"/>


== /etc/logrotate.conf & /etc/logrotate.d ==
== /etc/logrotate.conf и /etc/logrotate.d ==


The logrotate.conf configuration file largely dictates logrotate's behaviour, it holds global settings, but most of the work that logrotate does is via script files stored in the '''/etc/logrotate.d''' directory, which take precedence over the global settings held in logrotate.conf.
Файл конфигурации logrotate.conf в значительной степени определяет поведение logrotate - он содержит глобальные настройки, но большая часть работы, которую выполняет logrotate, осуществляется с помощью файлов сценариев, хранящихся в каталоге '''/etc/logrotate.d''', имеющими приоритет над глобальными настройками, содержащимися в logrotate.conf.


Applications such as Apache, MySQL, Cups & others, put scripts into the /etc/logrotate.d directory to manage their log files.
Такие приложения, как Apache, MySQL, Cups и другие, помещают скрипты в каталог /etc/logrotate.d для управления своими лог-файлами.


If you manually run the command '''sudo logrotate''', you will be presented with its usage template. logrotate needs you to specify the path to the script that you want it to use, including the logrotate.conf file which one may think due to its name would be automatically read, it is not.
Если вы вручную запустите команду '''sudo logrotate''' - вам будет представлен шаблон ее использования. logrotate требует указать путь к скрипту, который вы хотите использовать, включая файл logrotate.conf, который, как можно подумать из-за его названия, будет автоматически прочитан, но это не так.


To run logrotate & the logrotate.conf file you use the following command line:
Для запуска logrotate и файла logrotate.conf используется следующая команда:


  logrotate /etc/logrotate.conf
  logrotate /etc/logrotate.conf


<br clear="all"/>
<br clear="all"/>
=== Can I store & run my script files elsewhere? ===
=== Могу ли я хранить и запускать свои файлы скриптов в другом месте? ===
   
   
A line exists in logrotate.conf that tells logrotate to run all of the scripts that exist in /etc/logrotate.d  
В logrotate.conf есть строка, указывающая logrotate запускать все скрипты, существующие в /etc/logrotate.d  


  include /etc/logrotate.d
  include /etc/logrotate.d


We can use the '''include''' command in logrotate.conf to add other directories or use another directory instead of logrotate.d if we have reason to. Be careful what you do as there are files placed into the logrotate.d directory by other programs.
Мы можем использовать команду ''include'' в logrotate.conf для добавления других каталогов или использовать другой каталог вместо logrotate.d, если есть на то причины. Будьте осторожны в своих действиях, так как в каталог logrotate.d могут быть помещены файлы, созданные другими программами.


<br clear="all"/>
<br clear="all"/>
=== My settings in logrotate.conf don't effect all of the .log files? ===
=== Мои настройки в logrotate.conf не влияют на все .log файлы? ===


Script files that are called via the logrotate.conf file take precedence over the global settings in logrotate.conf . That means that if you call a script from logrotate.conf that is located in the /etc/logrotate.d directory, then that script is more powerful than any of the global setting in logrotate.conf .
Файлы сценариев, вызываемые через файл logrotate.conf, имеют приоритет над глобальными настройками в logrotate.conf. Это означает, что если вы вызываете скрипт из logrotate.conf, находящийся в каталоге /etc/logrotate.d, то этот скрипт будет более приоритетным, чем любые глобальные настройки в logrotate.conf .


I use a script '''/etc.logrotate.d/rotate.logs''' that is set to work on all *.log files, & it does. The two that don't get rotated are called '''faillog''' & '''lastlog''' , apart from not having the '''.log''' file extension, these two files are not normal log files, they are accessed via terminal commands of the same name.
Я использую скрипт '''/etc/logrotate.d/rotate.logs''', настроенный на работу со всеми *.log файлами, и он работает. Два неротируемых файла называются '''faillog''' и '''lastlog''', кроме того, что у них нет расширения '''log''', эти два файла не являются обычными файлами журнала, доступ к ним осуществляется через одноименные команды терминала.


<br clear="all"/>
<br clear="all"/>


=== Can I store my scripts where I want? ===
=== Могу ли я хранить свои скрипты где хочу? ===


Some applications such as Apache cups, drop scripts into /etc/logrotate.d to aid in their own self maintenance. We can use a location of our choosing for these or other scripts if we want. We just have to call its path in the /etc/logrotate.conf file, the same way, as shown in the following example:
Некоторые приложения, такие как Apache или cups, помещают скрипты в /etc/logrotate.d, чтобы помочь в их самообслуживании. Мы можем использовать для этих или других скриптов любое место по своему усмотрению. Мы просто должны указать путь к нему в файле /etc/logrotate.conf, как показано в следующем примере:


  include /home/handy/.config/mylogrotate
  include /home/handy/.config/mylogrotate


Apart from adding our own scripts to /etc/logrotate.d (or any other path that we have chosen to include), we can also add scripts into any of the previously mentioned '''/etc/ cron.hourly cron.daily cron.weekly cron.monthly''' folders. OR we can add a script into any of these folders that suit our needs that runs the logrotate /etc/logrotate.conf command which will have the logrotate.conf file, direct logrotate to the default /etc/logrotate.d directory where we have our script(s). OR to another directory where we have our script & have included the path in logrotate.conf . whew!
Помимо добавления собственных скриптов в /etc/logrotate.d (или по любому другому пути, который мы выбрали), мы также можем добавить скрипты в любой из ранее упомянутых каталогов '''/etc/ cron.hourly cron.daily cron.weekly cron.monthly'''. ИЛИ мы можем добавить скрипт в любой из этих каталогов, подходящих для наших нужд, запускающий команду logrotate /etc/logrotate.conf, которая будет имея файл logrotate.conf, направлять logrotate в каталог по умолчанию /etc/logrotate.d, где у нас есть наш скрипт(ы). ИЛИ в другой каталог, где находится наш скрипт, и вложенный (через include) в logrotate.conf. Вот это да!


So you can see there are a variety of ways to call logrotate (let alone use it).
Как видите, существует множество способов вызова logrotate (не говоря уже об его использовании).


<br clear="all"/>
<br clear="all"/>


== Some uses for Logrotate ==
== Некоторые варианты использования Logrotate ==


For example, script block below does the following, listed line by line:
Например, приведенный ниже блок сценария выполняет следующие действия, перечисленные построчно:


* '''/var/log/*.log {''' specifies the file or the files as this example uses a wild card that says all files ending in .log , the '''{''' starts the list of commands that will be used on the file(s) just specified.
* '''/var/log/*.log {''' указывает файл или файлы, так как в данном примере используется подстановочный знак, указывающий на все файлы, заканчивающиеся на .log , '''{''' начинает список команд, которые будут использоваться для только что указанного файла (файлов).


* '''daily''' Here we are saying cycle these commands daily, we can also say weekly, monthly, yearly (or specify other times with crontab)[http://www.adminschoice.com/crontab-quick-reference/].
* '''daily''' - здесь мы говорим о ежедневном цикле выполнения этих команд, мы также можем использовать еженедельно (weekly), ежемесячно (monthly), ежегодно (yearly) (или указать другое время с помощью crontab)[https://www.opennet.ru/man.shtml?topic=crontab&category=5&russian=0].


* '''size''' is where we can place a size limit that will cause a file to be rotated. I placed a '''1M''' one megabyte size limit in the example.
* '''size''' здесь мы можем установить ограничение на размер, которое приведет к ротации файла. В примере я установил ограничение размера '''1M''', т.е. в один мегабайт.


* '''dateext''' this puts the date of the rotation on the new copy, so it would use this format: '''<file.name>.log-20130815'''
* '''dateext''' помещает дату ротации на новую копию, так что она будет использовать такой формат: '''<имя_файла>.log-20221219'''


* '''rotate 7''' means keep 7 of our daily (in this script) backups, delete the oldest when it would become the 8th.
* '''rotate 7''' означает сохранение 7 ежедневных (в данном сценарии) резервных копий и удаление самой старой, когда она становится 8-й.


* '''compress''' is obvious, it uses gzip by default & adds a .gz extension to your file, which will make it look like this: <file.name>.log.1.gz you can choose other compression methods, I'm not going into that here.
* '''compress''' очевиден - использовать gzip по умолчанию и добавлять расширение .gz к файлу, в результате чего он будет выглядеть следующим образом: <имя_файла>.log.1.gz. Вы можете выбрать другие методы сжатия, я не буду вдаваться в подробности.


* '''delaycompress''' tells logrotate to compress the newly rotated file in the next cycle. This has advantages in ease of access & also if the file is still being written to by a process after it has been rotated.
* '''delaycompress''' указывает logrotate на сжатие только что ротированного файла в следующем цикле. Это имеет преимущества в простоте доступа, а также если файл все еще записывается процессом после того, как он был ротирован.


* '''copytruncate''' this is a great option, as it copies the contents of the file to a new new file <file.name>.log.1 & then deletes the contents of the original file. You can have no permission problems crop up when you do it this way.
* '''copytruncate''' - отличный вариант, так как он копирует содержимое файла в новый файл <имя_файла>.log.1 и затем удаляет содержимое исходного файла. При таком способе не возникнет проблем с разрешениями.


* '''notifempty''' do nothing if the file is empty, which makes good logical sense.
* '''notifempty''' ничего не делать если файл пуст, что имеет логический смысл.


* '''missingok''' if the file does not exist, give no error.
* '''missingok''' - если файл не существует, то не выдавать ошибку.


* '''}''' this curly bracket closes the block of commands.  
* '''}''' эта фигурная скобка закрывает блок команд.  


  /var/log/*.log {
  /var/log/*.log {
Line 288: Line 274:
   }
   }


The above script can be used as is, it does not need to be made executable, it just needs to be put somewhere that logrotate will see (in this example) every day.
Приведенный выше скрипт можно использовать как есть - его не нужно делать исполняемым, его просто нужно поместить в место, которое logrotate будет видеть (в данном примере) каждый день.


We can use the above script block as a template, easily removing parts & modifying its relatively simple settings. It can be duplicated in a script with each script block specifying custom settings tailored for individual files.
Мы можем использовать приведенный выше блок сценария в качестве шаблона, легко удаляя части и изменяя его относительно простые настройки. Он может быть продублирован в сценарии с каждым блоком, определяющим индивидуальные настройки для отдельных файлов.


<br clear="all"/>
<br clear="all"/>


== An Example that you can modify to suit ==
== Пример, который вы можете изменить в соответствии с требованиями ==


I'll show how I have my system set (at the time of this writing), you can use the information already given on this page & other available on the web to fine tune your set up to suit your needs (if you have the need anyway).
Я покажу как настроена моя система (на момент написания данной статьи), вы можете использовать информацию уже приведенную на этой странице и другую, доступную в Интернете, чтобы точно настроить свою систему в соответствии с вашими потребностями (если у вас вообще есть такая необходимость).


=== Firstly - Be sure this file is here /etc/cron.daily/logrotate ===
=== Во-первых - Убедитесь, что этот файл находится здесь /etc/cron.daily/logrotate ===
   
   
  #!/bin/sh
  #!/bin/sh
   
   
  # nicenesses range from -20 (most favorable scheduling) to 19 (least favorable)
  # приятности варьируются от -20 (наиболее благоприятное расписание) до 19 (наименее благоприятное)
  NICE=19
  NICE=19
   
   
  # 0 for none, 1 for real time, 2 for best-effort, 3 for idle
  # 0 - нет, 1 - в реальном времени, 2 - в лучшем режиме, 3 - в режиме ожидания
  IONICE_CLASS=2
  IONICE_CLASS=2
   
   
  # 0-7 (for IONICE_CLASS 1 and 2 only), 0=highest, 7=lowest
  # 0-7 (только для IONICE_CLASS 1 и 2), 0=высокий, 7=низкий
  IONICE_PRIORITY=7
  IONICE_PRIORITY=7
   
   
Line 326: Line 312:


<br clear="all"/>
<br clear="all"/>
=== Secondly - Create /etc/logrotate.d/rotate.logs using the following ===
=== Во-вторых - Создайте /etc/logrotate.d/rotate.logs, используя следующее ===


## rotate all /var/log files with names ending in log
  ## ротировать все файлы /var/log с именами, заканчивающимися на log
  /var/log/*log {
  /var/log/*log {
  ## cycle through these commands once per day
  ## выполнять эти команды один раз в день
   daily
   daily
  ## keep the results of 7 cycles
  ## сохранять результаты 7 циклов
   rotate 7
   rotate 7
  ## use gzip to compress each rotated (copied) log file
  ## использовать gzip для сжатия каждого ротированного (скопированного) файла журнала
   compress
   compress
  ## compress the file on the next cycle
  ## сжимать файл на следующем цикле
   delaycompress
   delaycompress
  ## copy the contents of the log file to a new file <name>.log.1
  ## скопировать содержимое файла журнала в новый файл <имя>.log.1
  ## & then delete the contents of the original log file
  ## и затем удалить содержимое исходного файла
   copytruncate
   copytruncate
  ## do nothing to empty files
  ## ничего не делать с пустыми файлами
   notifempty
   notifempty
  ## create no errors if a file is missing
  ## не выдавать ошибок если файл отсутствует
   missingok
   missingok
  ## after the files have been rotated run the following command
  ## после того, как файлы будут ротированы, выполнить следующую команду
   }  
   }  


<br clear="all"/>
<br clear="all"/>


=== A Summary of the above example thus far ===
=== Краткое изложение приведенного выше примера на данный момент ===


The First step puts a file into '''/etc/cron.daily''' which is an easy way to add the script to a daily cron job. Which means that script will be run everyday.
Первый шаг помещает файл в '''/etc/cron.daily''', что является простым способом добавить скрипт в ежедневное задание cron. Это означает, что скрипт будет выполняться каждый день.


It basically runs this command:
По сути, он выполняет эту команду:


  logrotate /etc/logrotate.conf
  logrotate /etc/logrotate.conf


As logrotate.conf goes through its list of commands it calls this one:
Когда logrotate.conf проходит через свой список команд - он вызывает эту команду:


  include /etc/logrotate.d
  include /etc/logrotate.d


Which means that any scripts that are inside of '''/etc/logrotate.d''' are also run.
Это означает что все скрипты, находящиеся внутри '''/etc/logrotate.d''', также будут запущены.


This brings us to the second step (above), where we created '''/etc/logrotate.d/rotate.logs''' . This script will be run everyday. The comments I added to the rotate.logs file above give a general idea of what it does. You can delete, modify & add to that script, but do it carefully.
Это подводит нас ко второму шагу (выше), где мы создали '''/etc/logrotate.d/rotate.logs'''. Этот скрипт будет выполняться каждый день. Комментарии, которые я добавил к файлу rotate.logs, дают общее представление о том, что он делает. Вы можете удалять, изменять и дополнять этот скрипт, но делайте это с осторожностью.


=== The effect of running /etc/logrotate.d/rotate.logs everyday ===
=== Эффект от ежедневного запуска /etc/logrotate.d/rotate.logs ===


Is that any file in /var/log that had '''log''' at the end of its name will be processed by the commands in the '''rotate.logs''' script. This will back up these files to a new file '''<name>.log.1''' & empty the original file to size 0. Any previous copies with '''<name>.log.<number>''' will have their numbers bumped up one, until the day when they would have been given an 8, that is the day that they are deleted.
Это означает, что любой файл в /var/log, имеющий '''log''' в конце своего имени, будет обработан командами скрипта '''rotate.logs'''. Это приведет к резервному копированию этих файлов в новый файл '''<имя>.log.1''' и очистке содержимого исходного файла. Все предыдущие копии с '''<имя>.log.<номер>''' будут иметь номера, увеличенные на единицу до дня, когда им будет присвоена цифра 8, то есть до дня, когда они будут удалены.


As well as this rotating (copying) & renaming of files, all files will be compressed in gzip format on the next rotation. Which means that you always have the current file & yesterdays file in /var/log in uncompressed format.  
Помимо ротации (копирования) и переименования файлов, все файлы будут сжаты в формате gzip при следующей ротации. Это означает, что в /var/log всегда есть текущий файл и файл вчерашнего дня в несжатом формате.  


No files that are empty will be processed, & a file being missing will throw no errors.
Пустые файлы обрабатываться не будут, а отсутствующий файл не вызовет ошибок.


<br clear="all"/>
<br clear="all"/>
=Support=
Following is a link to this page's forum counterpart where you can post any related feedback: [https://forum.manjaro.org/t/wiki-limit-the-size-of-log-files-the-journal/17875]


[[Category:Contents Page{{#translation:}}]]
[[Category:Contents Page{{#translation:}}]]

Latest revision as of 06:07, 13 February 2023

Other languages:
English • ‎Türkçe • ‎русский

Введение

Примечание
18-фев-17: Обновлен раздел "Журнал" и создана страница поддержки на форуме.

12-фев-14: Улучшен раздел "Журнал".

24-мар-14: Приведено в порядок содержание страницы и добавлено содержание следующего раздела.

Файлы журналов и журнал systemd делают одно и то же, но по-разному. Они ведут запись всего, что происходит в вашей системе. Это позволяет понять что работает правильно, а что - нет. Например, если ваша система подверглась ssh-атаке - это может быть отобажено в логе/журнале. Таким образом, эти журналы полезны не только для отслеживания проблем с оборудованием, драйверами, плохо написанным кодом сетевого менеджера или множества других проблем, с которыми приходится сталкиваться сложной и динамичной системе GNU/Linux.

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

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


В первой теме на этой странице будет кратко рассмотрен журнал systemd

Журнал systemd занял место файлов журналов, хотя он прекрасно работает параллельно с файлами журналов стандартного типа. Они по-прежнему создаются и поддерживаются по умолчанию в Arch и Manjaro. Если вы удалите syslog-ng и все файлы /var/log/*log, то при перезагрузке обнаружите что некоторые файлы логов будут созданы снова автоматически. На моей машине после удаления syslog-ng и всех файлов /var/log/*.log (за исключением Xorg.0.log), моя машина теперь имеет следующее содержимое (wtmp и btmp создаются при загрузке файлом /etc/logrotate.conf) в /var/log/: 

journal/
squid/
Xorg.0.log
Xorg.0.log.old
btmp
faillog
lastlog
pacman.log
wtmp


Вторая тема будет посвящена работе с файлами журналов

Эта тема будет более глубокой - в ней мы рассмотрим использование команды logrotate, logrotate.conf, /etc/cron.daily cron.weekly cron.monthly cron.yearly и некоторые способы запуска созданных скриптов, а также упомянем метод запуска скрипта crontab. Я постараюсь сделать этот раздел доступным для как можно большего числа людей, а это означает что страница будет довольно длинная.


Журнал и логи дублируют одну и ту же информацию

Вы можете читать текст файлов логов в текстовом редакторе или с помощью команд cat, more, less и подобных, как и для любого другого текстового файла. Журнал же требует команды journalctl для доступа к его содержимому. Ниже приведен хороший способ чтения журнала: 

sudo journalctl


Прочитайте это - это важно

Примечание
/etc/systemd/journald.conf.d/*.conf переопределяет файл journald.conf

man journald.conf

Когда пакетам необходимо настроить конфигурацию - они могут установить фрагменты конфигурации в /usr/lib/systemd/*.conf.d/. Файлы в /etc/ зарезервированы для локального администратора, который может использовать эту логику для переопределения конфигурационных файлов, установленных пакетами вендора. Главный конфигурационный файл читается перед любым из каталогов конфигурации и имеет наименьший приоритет; записи в файле в любом каталоге конфигурации переопределяют записи в единственном файле конфигурации. Файлы в подкаталоге конфигурации *.conf.d/ сортируются по имени файла в лексикографическом порядке, независимо от того, в каком из подкаталогов они находятся. Если в нескольких файлах указана одна и та же опция, приоритет имеет запись в файле с самым лексикографически последним именем. Рекомендуется снабжать все имена файлов в этих подкаталогах двузначным числом и тире для упрощения упорядочивания файлов.

Это означает, что вы можете создавать конфигурационные файлы .conf в каталоге /etc/systemd/journald.conf.d/ с подходящими именами по вашему выбору. Содержимое этих файлов имеет приоритет над любыми другими настройками или конфигурациями в systemd. Пожалуйста, имейте это в виду, когда будете читать следующее. В своей многословной манере я попытался сделать все это слишком очевидным...


Как установить ограничение на максимальный размер журнала

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

Используйте ваш любимый текстовый редактор с привилегиями root (запустите его с помощью sudo).


Примечание
файл size.conf создается пользователем

С помощью текстового редактора создайте файл под названием size.conf в следующем месте /etc/systemd/journald.conf.d/size.conf. Следующий файл устанавливает максимальный размер файла в 50 МБ для /var/log/journal . (SystemMaxUse=250M предназначено для использования с logrotate, рассматриваемыми во втором разделе этой страницы. Поговорите с papajoke на форуме если вам нужна помощь с logrotate и systemd.) 

[Journal]
SystemMaxUse=250M
SystemMaxFileSize=50M

Вы также можете ограничить содержимое журнала, указав уровень данных, добавляемых в журнал. Это делается путем создания и редактирования файла /etc/systemd/journald.conf.d/level.conf. 

Примечание: файл level.conf создается пользователем.

[Journal]
# не сохранять все уровни, а только от 0 до 4
MaxLevelStore=warning


Команда Journalctl - краткое руководство [1]

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

Вы не должны использовать "sudo" с journalctl

Добавьте вашего пользователя в группу adm. Это даст вашему <пользователю> полное право использовать команду journalctl. Больше не нужно использовать sudo. Поменяйте "handy" на ваше имя пользователя в следующих строках: 

# usermod -a -G adm handy

Посмотреть всю строку вывода journalctl

Вы можете передать вывод journalctl в файл или в инструмент отображения текста, например, "More" или "Less", следующим образом: 

$ journalctl -b -p err|less

Это позволит избежать усечения вывода, которое может наблюдаться в некоторых конфигурациях дисплеев.

Используйте альяс ~/.bashrc чтобы сделать это проще

Я использую следующий альяс ~/.bashrc: 

alias errors="journalctl -b -p err|less"

При вводе errors в терминале, все ошибки или проблемы с момента последней загрузки отправляются (передаются) в инструмент отображения текста в терминале под названием Less, который оборачивает текстовый вывод команды journalctl. Помимо этого, он делает ошибки более удобочитаемыми для тех, кто будет читать их на форуме!

Введите q (в верхнем или нижнем регистре) чтобы закрыть "Less".


Доступ к полному журналу, содержащему информацию о системе и пользователях:

$ journalctl

Просмотр в реальном времени - показывает последние 10 строк журнала и все содержимое по мере того как он пополняется:

$ journalctl -f

Основная фильтрация:

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

$ journalctl -b

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

$ journalctl -b -p err

Ниже приведена команда, вывод которой отправляется в файл с именем -ERRORS в каталоге /home/<user>. Наличие символа - в начале имени должно привести к тому, что файл будет отображаться в самом начале списка файлов при просмотре содержимого вашего каталога ~/ (/home/<user>). Эта команда позволяет легко скопировать содержимое файла -ERRORS, а затем вставить его на форум. Это дает нам возможность отобразить ВЕСЬ вывод команды, а не только вырезать и вставлять усеченные строки из терминала: 

$ Journalctl -b -p err > -ERRORS

Фильтрация по времени:

Со вчерашнего дня:

$ journalctl --since=yesterday

Указать конкретный период времени:

$ journalctl --since=2012-10-15 --until="2011-10-16 23:59:59"

Выбрать конкретную службу и период времени:

$ journalctl -u httpd --since=00:00 --until=9:30

Указать journalctl на определенные устройства, сервисы, двоичные файлы

Просмотр конкретного устройства:

$ journalctl /dev/sdc

Проверка бинарного файла:

$ journalctl /usr/sbin/vpnc

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

$ journalctl /usr/sbin/vpnc /usr/sbin/dhclient

Показать все модули systemd, запущенные в вашем журнале:

$ journalctl -F _SYSTEMD_UNIT

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

Резюмируя

Журнал Systemd способен выполнять расширенные функции, выходящие за рамки того, что было упомянуто здесь. Вышеизложенное является очень хорошей пищей для размышлений людям, задающимся вопросом, нужно ли им запускать syslog-ng или что-то подобное, создающее множество файлов /var/log/*log в их системах.

Экспериментируя с приведенными выше командами, можно принять обоснованное решение, хотя, как уже упоминалось в начале раздела "Журнал", Arch и, соответственно, Manjaro все еще работают параллельно с новым журналом systemd и файловой системой журналов старого стиля. Поэтому, если вы считаете файлы /var/log/*log избыточными и хотите избавиться от них - эффективными будут различные методы.

На данный момент я запускаю свою систему с удаленным syslog-ng (и его зависимостью). Я удалил все файлы журналов из каталога /var/log (оставив тоько находящиеся в собственных подкаталогах), кроме Xorg.0.log, Xorg.0.old, lastlog, btmp и wtmp, (pacman.log появлялся при использовании pacman, в зависимости от того, что у вас установлено в системе, у вас могут быть приложения, создающие свои собственные журналы - которые можно отключить).

Примечание
В настоящее время я не использую systemd, так как с удовольствием пользуюсь системой инициализации OpenRC.


Управление файлами /var/log/*

Представляем Logrotate и друзей

Что такое Logrotate? [2] logrotate - это мощный инструмент, используемый для управления лог-файлами, создаваемыми системными процессами. Его можно настроить на автоматическое сжатие, переименование различными способами, удаление журналов, на выполнение всего этого и многого другого таким образом, чтобы максимально повысить удобство использования журналов и сэкономить ресурсы системы. Пользователям доступно огромное количество средств контроля, включая запуск скриптов на ваших ротируемых файлах.

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

Например, logrotate может быть вызван для запуска файла или нескольких файлов в любой комбинации или кратности ежечасно (hourly), ежедневно (daily), еженедельно (weekly), ежемесячно (monthly) и ежегодно (yearly), через скрипты, размещенные в /etc/ в уже существующих каталогах hourly daily weekly monthly (каталог yearly может быть добавлен при необходимости). crontab [3] можно использовать для запуска logrotate или настолько сложных скриптов, насколько это необходимо. logrotate можно комбинировать с другими инструментами, которые пользователь может придумать для обработки этих ротируемых файлов в любое время и с любой частотой.


Область применения данной статьи

Тем не менее, большая часть возможностей logrotate предназначена для администраторов серверов и не будет рассматриваться ниже. Хотя то, что мы рассмотрим, может быть использовано не только для файлов журналов. Мы можем использовать logrotate для резервного копирования любых других файлов по своему усмотрению. Я расскажу об этом позже.


/etc/logrotate.conf и /etc/logrotate.d

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

Такие приложения, как Apache, MySQL, Cups и другие, помещают скрипты в каталог /etc/logrotate.d для управления своими лог-файлами.

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

Для запуска logrotate и файла logrotate.conf используется следующая команда: 

logrotate /etc/logrotate.conf


Могу ли я хранить и запускать свои файлы скриптов в другом месте?

В logrotate.conf есть строка, указывающая logrotate запускать все скрипты, существующие в /etc/logrotate.d 

include /etc/logrotate.d

Мы можем использовать команду include в logrotate.conf для добавления других каталогов или использовать другой каталог вместо logrotate.d, если есть на то причины. Будьте осторожны в своих действиях, так как в каталог logrotate.d могут быть помещены файлы, созданные другими программами.


Мои настройки в logrotate.conf не влияют на все .log файлы?

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

Я использую скрипт /etc/logrotate.d/rotate.logs, настроенный на работу со всеми *.log файлами, и он работает. Два неротируемых файла называются faillog и lastlog, кроме того, что у них нет расширения log, эти два файла не являются обычными файлами журнала, доступ к ним осуществляется через одноименные команды терминала.


Могу ли я хранить свои скрипты где хочу?

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

include /home/handy/.config/mylogrotate

Помимо добавления собственных скриптов в /etc/logrotate.d (или по любому другому пути, который мы выбрали), мы также можем добавить скрипты в любой из ранее упомянутых каталогов /etc/ cron.hourly cron.daily cron.weekly cron.monthly. ИЛИ мы можем добавить скрипт в любой из этих каталогов, подходящих для наших нужд, запускающий команду logrotate /etc/logrotate.conf, которая будет имея файл logrotate.conf, направлять logrotate в каталог по умолчанию /etc/logrotate.d, где у нас есть наш скрипт(ы). ИЛИ в другой каталог, где находится наш скрипт, и вложенный (через include) в logrotate.conf. Вот это да!

Как видите, существует множество способов вызова logrotate (не говоря уже об его использовании).


Некоторые варианты использования Logrotate

Например, приведенный ниже блок сценария выполняет следующие действия, перечисленные построчно:

  • /var/log/*.log { указывает файл или файлы, так как в данном примере используется подстановочный знак, указывающий на все файлы, заканчивающиеся на .log , { начинает список команд, которые будут использоваться для только что указанного файла (файлов).
  • daily - здесь мы говорим о ежедневном цикле выполнения этих команд, мы также можем использовать еженедельно (weekly), ежемесячно (monthly), ежегодно (yearly) (или указать другое время с помощью crontab)[4].
  • size здесь мы можем установить ограничение на размер, которое приведет к ротации файла. В примере я установил ограничение размера 1M, т.е. в один мегабайт.
  • dateext помещает дату ротации на новую копию, так что она будет использовать такой формат: <имя_файла>.log-20221219
  • rotate 7 означает сохранение 7 ежедневных (в данном сценарии) резервных копий и удаление самой старой, когда она становится 8-й.
  • compress очевиден - использовать gzip по умолчанию и добавлять расширение .gz к файлу, в результате чего он будет выглядеть следующим образом: <имя_файла>.log.1.gz. Вы можете выбрать другие методы сжатия, я не буду вдаваться в подробности.
  • delaycompress указывает logrotate на сжатие только что ротированного файла в следующем цикле. Это имеет преимущества в простоте доступа, а также если файл все еще записывается процессом после того, как он был ротирован.
  • copytruncate - отличный вариант, так как он копирует содержимое файла в новый файл <имя_файла>.log.1 и затем удаляет содержимое исходного файла. При таком способе не возникнет проблем с разрешениями.
  • notifempty ничего не делать если файл пуст, что имеет логический смысл.
  • missingok - если файл не существует, то не выдавать ошибку.
  • } эта фигурная скобка закрывает блок команд.
/var/log/*.log {
 daily
 size 1M
 dateext
 rotate 7
 compress
 delaycompress
 copytruncate
 notifempty
 missingok
  }

Приведенный выше скрипт можно использовать как есть - его не нужно делать исполняемым, его просто нужно поместить в место, которое logrotate будет видеть (в данном примере) каждый день.

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


Пример, который вы можете изменить в соответствии с требованиями

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

Во-первых - Убедитесь, что этот файл находится здесь /etc/cron.daily/logrotate

#!/bin/sh

# приятности варьируются от -20 (наиболее благоприятное расписание) до 19 (наименее благоприятное)
NICE=19

# 0 - нет, 1 - в реальном времени, 2 - в лучшем режиме, 3 - в режиме ожидания
IONICE_CLASS=2

# 0-7 (только для IONICE_CLASS 1 и 2), 0=высокий, 7=низкий
IONICE_PRIORITY=7

CMD_LOGROTATE="/usr/bin/logrotate /etc/logrotate.conf"

if [ -x /usr/bin/nice ]; then
  CMD_LOGROTATE="/usr/bin/nice -n ${NICE:-19} ${CMD_LOGROTATE}"
fi

if [ -x /usr/bin/ionice ]; then
  CMD_LOGROTATE="/usr/bin/ionice -c ${IONICE_CLASS:-2} -n ${IONICE_PRIORITY:-7} ${CMD_LOGROTATE}"
fi

${CMD_LOGROTATE}

exit 0


Во-вторых - Создайте /etc/logrotate.d/rotate.logs, используя следующее

 ## ротировать все файлы /var/log с именами, заканчивающимися на log
/var/log/*log {
## выполнять эти команды один раз в день
 daily
## сохранять результаты 7 циклов
 rotate 7
## использовать gzip для сжатия каждого ротированного (скопированного) файла журнала
 compress
## сжимать файл на следующем цикле
 delaycompress
## скопировать содержимое файла журнала в новый файл <имя>.log.1
## и затем удалить содержимое исходного файла
 copytruncate
## ничего не делать с пустыми файлами
 notifempty
## не выдавать ошибок если файл отсутствует
 missingok
## после того, как файлы будут ротированы, выполнить следующую команду
  }


Краткое изложение приведенного выше примера на данный момент

Первый шаг помещает файл в /etc/cron.daily, что является простым способом добавить скрипт в ежедневное задание cron. Это означает, что скрипт будет выполняться каждый день.

По сути, он выполняет эту команду: 

logrotate /etc/logrotate.conf

Когда logrotate.conf проходит через свой список команд - он вызывает эту команду: 

include /etc/logrotate.d

Это означает что все скрипты, находящиеся внутри /etc/logrotate.d, также будут запущены.

Это подводит нас ко второму шагу (выше), где мы создали /etc/logrotate.d/rotate.logs. Этот скрипт будет выполняться каждый день. Комментарии, которые я добавил к файлу rotate.logs, дают общее представление о том, что он делает. Вы можете удалять, изменять и дополнять этот скрипт, но делайте это с осторожностью.

Эффект от ежедневного запуска /etc/logrotate.d/rotate.logs

Это означает, что любой файл в /var/log, имеющий log в конце своего имени, будет обработан командами скрипта rotate.logs. Это приведет к резервному копированию этих файлов в новый файл <имя>.log.1 и очистке содержимого исходного файла. Все предыдущие копии с <имя>.log.<номер> будут иметь номера, увеличенные на единицу до дня, когда им будет присвоена цифра 8, то есть до дня, когда они будут удалены.

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

Пустые файлы обрабатываться не будут, а отсутствующий файл не вызовет ошибок.


Retrieved from "https://wiki.manjaro.org/index.php?title=Limit_the_size_of_.log_files_%26_the_journal/ru&oldid=45864"