Как удалить syslog ubuntu
Обновлено: 06.07.2024
При входе в систему с Ubuntu я получаю предупреждение о том, что мне не хватает места на диске. Проследив назад, я обнаружил, что это системные журналы, особенно kern.log (ы), которые съедают мой диск емкостью 1 ТБ.
Из приведенного выше фрагмента вы легко можете обнаружить, что kern.log и kern.log.1 занимают 80% моего диска размером 1 ТБ. Я могу получить место, удалив файлы, но думаю, это не решит проблему.
Кто-нибудь знает, в чем может быть проблема? Я видел, что вы можете получить уровень ведения журнала:
3 ответа
Вы проверили содержимое этих файлов? Очевидно, что с вашим сервером что-то происходит, вызывая генерацию событий. Устраните любую проблему, которая вызывает это, и ваши журналы должны вернуться к своему нормальному размеру.
- Принятый ответ не объясняет, почему проблема с диском исчезнет, если вы исправите основную проблему системы (ответ: logrotate ), плюс ваша система может продолжать писать в журналы и заполнять ваш диск, прежде чем вы даже сможете понять из основной проблемы.
- Другой ответ полностью удаляет и отключает журналы, что не является хорошим подходом, поскольку он игнорирует основную проблему. Кроме того, вам, вероятно, понадобятся эти файлы журналов позже, когда вы будете выяснять другие системные проблемы - отключение syslog затрудняет отслеживание будущих проблем!
Вместо этого существует более безопасный метод, который позволяет вам сохранить файлы журнала, освобождая дисковое пространство, а также не позволяя файлам журнала делать это снова.
Безопасно очистите журналы: после просмотра журналов (или резервного копирования) для определения проблемы вашей системы очистите их, набрав > /var/log/syslog (включая > ). Для этого вам может потребоваться быть пользователем root, в этом случае введите sudo su , свой пароль, а затем указанную выше команду).
Затем вы можете заставить журналы вращаться и автоматически удалять, если они достигают определенного размера, используя logrotate . В этом случае вы можете отредактировать конфигурацию с помощью sudo nano /etc/logrotate.d/rsyslog и добавить одну строку:
- Это заставит ваш syslog «повернуться» (т.е. создать новый файл журнала и заархивировать предыдущий файл журнала) либо через 1 день, либо когда размер файла станет 1 ГБ, в зависимости от того, что наступит раньше. Обратите внимание: rotate 7 означает, что ваша система будет хранить всего 7 резервных копий syslog , поэтому она может занимать не более 7 ГБ пространства.
- Примечание: вы можете изменить maxsize , rotate N и другие настройки для настройки ваших журналов - используйте команду man logrotate , чтобы увидеть больше.
- Пока вы это делаете, вы можете добавить во вторую часть файла тот же параметр, который управляет поведением других файлов журнала (например, kern.log для событий ядра, auth.log для событий аутентификации , и т.д.). Этот параметр сделает так, что каждый из этих других файлов журнала будет занимать всего 4 ГБ:
Это позволит вашей системе вести журнал событий, не заполняя диск.
Для получения дополнительной информации см. руководство и аналогичный вопрос.
Недавно начал качать усиленно с торрентов, покачав несколько дней заметил что на системном диске с Ubuntu 10.04 — резко пропало 8 гб . Поставив на проверку веса дерикторий обноружил что всему причиной файлы находящиеся в var/log:
мы увидем что то подобное:
Разобратся с этим нам поможет вот эта таблица:
Параметр Описание
rotate <число> Количество хранимых файлов
daily
weekly
monthly игнорировать размер файла; Производить ротацию раз в день/неделю/месяц
size <байт>
size 1000
size 100k
size 1M Производить ротацию если log-файл превысил указанный размер
байт
Кбайт
Мбайт
start <число> число с которого начнётся нумерация файлов
compress Архивировать файлы (по умолчанию gzip)
nocompress Отключает compress
delaycompress Не сжимать 'свеже' созданный архив. Например access.log.1 не будет зжат.
Используется с compress
create <права><владелец><группа>
create 640 root root После ротации создать пустой log-файл. Любые из этих атрибутов могут быть опущены,
в этом случае вместо них для нового файла будут использованы атрибуты,
имеющие те же значения, что и первоначальный log-файл
copy Создать копию оригинального log-файла, не изменяя его. Исключает create
nocopy Отключает copy
copytruncate Создать копию оригинального log-файла, а потом его 'обнулить'.
Таким образом сам файл не удаляется.
Исключает copy, create
ifempty Архивирует даже пустой файл (используется по умолчанию)
notifempty Не архивировать пустые файлы
missingok В случае отсутствия оригинального log-файла не вызовет ошибку
nomissingok В случае отсутствия оригинального log-файла вызовет ошибку
postrotate
<команды>
endscript Строки, находящиеся между postrotate и endscript
будут выполнены как sh скрипт после архивирования log-файла
prerotate
<команды>
endscript Аналогично postrotate, только действия будут выполнены до начала архивирования
sharedscripts Скрипты postrotate и prerotate будут выполнены только один раз в рамках своей секции.
nosharedscripts Отключает sharedscripts.
Скрипты будут выполняются при ротации каждого log-файла,
при определение /var/log/apache2/*.log скрипт будет выполнен столько раз
сколько уникальных log-файлов будет находится в данной директории
olddir <путь>
olddir /home/logsПеремещать архивные файлы в указанную директорию
noolddir Отключает olddir
Команды пишутся после строки с местом нахождения лога- например:
Так как же нам оптимизировать лог — вот пример как это настроенно у меня:
rsyslog:
В данном случае указанно что логи после превышения определенного размера будут ротироватся(не по неделям как это было до оптимизации) и их максимальное количество будет не больше 3х штук в сжатом виде — стоит заметить после обновления конфига советую подчистить старые логи настройки которых мы оптимизировали(возможно они много весят) — можно их просто удалить под правами администратора(тока осторожнее не переусердствуйте) — после перезагрузки они создадутся автоматически.
И уйти в перезагрузку.
Надеюсь вам поможет моя статья в оптимизации ubuntu .
The systemd journal is systemd’s own logging system. It is equivalent to the syslog in the init system. It collects and stored kernel logging data, system log messages, standard output and error for various systemd services.
A Linux machine with systemd writes the logs to /var/log/journal directory. If you remember the Linux directory structure, /var is where the system logs are stored.
You can either manually view the log files using less command or use the journalctl command. To view all the latest logs, use the command with reverse option.
The thing with logging is that over the time, it starts to grow big. And if you check the disk space in Linux, you’ll see that sometimes, it takes several GB of space.
Let me show you how to clean systemd journal logs and free up disk space on your Linux system.
Clearing systemd journal logs
First check the space taken by journal logs with the du command:
You can also use the journalctl command for the same task:
Both of the command should give approximately the same result:
Now that you know how much space the journal logs take, you can decide if you want to clear the logs or not. If you decide to clear the journal logs, let me show you a couple of ways of doing it.
You can of course use the rm command to delete the files in the log folder but I won’t advise that. The journalctl command gives you the proper way of handling old logs.
First thing you should do is to rotate journal files. This will mark the currently active journal logs as archive and create fresh new logs. It’s optional but a good practice to do so.
Now you have three ways to clear old journal logs. You delete logs older than a certain time or you delete older log files so that total log size is limited to the predefined disk space or you limit number of log files. Let’s see how to use all three methods.
1. Clear journal log older than x days
Keep in mind that logs are important for auditing purpose so you should not delete all of them at the same time. Let’s say you want to keep the log history of just two days. To delete all entries older than two days, use this command:
Here’s what the output may look like:
You can also change the provide time frame in hours like 2h, in minutes like 2m, in seconds like 2s. If you want bigger time units, you can 2weeks, 2months as well.
2. Restrict logs to a certain size
Another way is to restrict the log size. With this, it will delete the journal log files until the disk space taken by journal logs falls below the size you specified.
This will reduce the log size to around 100 MB.
You can specify the size in GB with G, MB with M, KB with K etc.
3. Restrict number of log files
The third way is to limit the number of log files. The journalctl usually has log files for the system and for the users. As the logs get old they are archived in various files.
You can limit the number of archive log files. Let’s say you want to have only five log files.
It will remove the older archive log files leaving only the specified number of log files.
How to Use journalctl Command to Analyze Logs in Linux Beginner’s guide to using journalctl commands for viewing, filtering and analyzing journal logs in Linux. Linux Handbook Abhishek Prakash
Automatically clearing old log files [Requires intermediate knowledge of command line]
What you just did will clean the log files for now. In a month the logs will increase again. You can manually clean them with one of the methods described above. But that is a tedious task and you may not remember to do that regularly.
The good thing is that you can configure systemd to automatically handle old log files.
The journalctl has configuration file at /etc/systemd/journald.conf. There are settings which are commented out. The commented lines basically indicate the default value of those settings parameters (even if they are commented out).
You can change some of these default settings to automatically clean the log files.
You would want to change the following settings:
| Setting | Description |
|---|---|
| SystemMaxUse | Max disk space logs can take |
| SystemMaxFileSize | Max size of an INDIVIDUAL log file |
| SystemMaxFiles | Max number of log files |
Please note that you should be careful while editing configuration files. You must be comfortable using a terminal-based text editor like Vim, Emacs or Nano so that you don’t make silly mistakes while editing the conf file.
I advise to make a backup of the configuration file first:
You’ll have to use Vim or some other terminal based editor in order to edit this configuration file. Here’s what it looks like me after editing the file.
Keep in mind that after editing the configuration file, you should load the changes:
The journald.conf file can be used to tweak the journalctl settings even further. You can even set the levels of log (info, debug, error etc) you want to see. It’s up to you if you want to change those settings as well.
How to List Systemd Services in Linux [Beginner’s Guide] Check what systemd services run on your Linux system in this tutorial. Linux Handbook Abhishek Prakash
I hope you like this tip to clear systemd journal log files. If you have any questions or suggestions, please leave a comment below.
Попытка настроить Rsyslog Клиент для отправки журналов на Rsyslog Server.
Обе машины работают на Centos7 с Vagrant.
Смотрите конфигурацию каждой машины ниже.
Когда я захожу внутрь клиентского компьютера - это не отражается в логах сервера.
Но когда я добавляю IP-адрес сервера в команду:
Я вижу, что на компьютере сервера создается каталог с IP-адресом клиента:
Вопрос. Есть идеи, почему я не вижу локальные журналы Клиента?
Для этого обсуждения:
Конфигурация Rsyslog
IP-адрес сервера: 192.168.11.11 .
IP-адрес клиента: 192.168.11.22 .
На обеих машинах установлен и включен rsyslog, а в файле /etc/rsyslog.conf имеются следующие общие настройки:
Дополнения для каждой машины в файле /etc/rsyslog.conf .
На компьютере Сервер :
На компьютере Клиент я настраиваю переадресацию UDP на IP-адрес сервера:
Конфигурация брандмауэра
На компьютере Сервер - открытие порта 514 в брандмауэре:
2 ответа
Попробуйте удалить один пробел после *. на хосте клиента:
*. * @192.168.11.11:514
Формат по умолчанию для отправки журналов любого уровня на удаленном хосте выглядит следующим образом:
*.* @remote-host:514
Затем перезапустите службу rsyslog на клиенте и сервере с помощью systemctl restart rsyslog и проверьте снова.
Вставлено из комментариев - еще 2 шага, которые были сделаны на сервере системного журнала, который решил проблему:
Благодарю @Alexey, который помог мне в двух критических моментах.
Я также добавлю еще несколько полезных моментов, которые могут быть полезны для других:
1: Прежде всего, проверьте соединение двух машин. Например, если используется бродячая сеть, переведите две машины в сетевой режим, чтобы они могли видеть (пинговать) друг друга. Например, режим Host-only работает нормально, но внутренний режим, когда каждая машина находится в своей изолированной сети, не будет работать.
2. Раскомментирование следующего кода требуется только на сервере системного журнала:
4: Быстрая проверка, чтобы увидеть, если соединение UDP успешно:
Пересылать журналы авторизации на сервер (например, auth,authpriv.* @192.168.11.11:514 ).
Ssh на клиентском компьютере, переключайтесь между пользователями и просматривайте следующие файлы в каталоге / var / log / на сервере:
5. Будьте осторожны с синтаксисом rsyslog - например, если вы используете sed как часть сценария обеспечения для замены и редактирования строк в файле конфигурации - проверьте вывод:
Указание секции $ template в одной строке:
Приведет к ошибке:
Авг 03 13:50:04 сервер rsyslogd [5539]: ошибка: дополнительные символы в строка конфигурации игнорируется: '. ? RemoteLogs' [v8.24.0-34.el7]
Это правильный синтаксис - разбить правило на новую строку (если сгенерировано с помощью sed - просто добавьте /n ):
7: Более новые версии rsyslog (я думаю, 5+) поддерживают гораздо более чистый синтаксис - теперь он используется по умолчанию в новых версиях Ubuntu, например, но по какой-то причине не в Centos7.
8. На syslog-сервере - убедитесь, что ваш брандмауэр включен и настроен на прием UDP по соответствующему порту (см. Вопрос в скрипте конфигурации):
Читайте также: