Var log messages linux можно удалить

/var/log/messages

Решил почистить /var/log/messages и удалил его и создал заново, но там не появляются новые логи, как сделать чтобыь туда писались логи без перезагрузки т.к. не хочитсья портить аптайм

Re: /var/log/messages

Re: /var/log/messages

Re: /var/log/messages

Re: /var/log/messages

а права на запись не забыл поставить?

Re: /var/log/messages

а не слишком ли расточительно будет копировать километровые файлы, когда «перезапуск» syslog_a — это kill -HUP $sylog_pid .

Re: /var/log/messages

А мож logrotate прикрутить чтоб руками не лазить каждый раз?

Re: /var/log/messages

> Решил почистить /var/log/messages и удалил его и создал заново

А не проще это делать cat /dev/null > /var/log/messages

Re: /var/log/messages

Откуда километры на домашней машине? Да даже если и так, прикрутить logrotate, он делает примерно то же самое, и забыть.

Ну или не `cp . . `, а `cat . | bzip2 -9 > messages.1.bz2`, прям разница.

Re: /var/log/messages

Re: /var/log/messages

> Да потому, что это абсолютно не правильно.
> Здесь есть риск потери информации, в то время как при таком раскладе:
> mv /var/log/messages /var/log/messages.old
> cat /dev/null > /var/log/messages
> kill -HUP $syslog_pid
> нет риска потери информации.
> Учите мат. часть (работа с открытыми на запись файлами)

Смею заметить, что между `mv` файла и SIGHUP’ом тоже возникает риск потери информации, т.к. syslog пишет в уже удаленный файл — точно такой же, как и в моем примере. Идеальный вариант — писать в 2 лога, удалять один из них и проверять не потерялось ли чего.

Либо комбинация: `cp /var/log/messages /var/log/messages.old && cat /dev/null > /var/log/messages`, при которой не требуется перезапуск syslog, да риск потерь так же невелик.

kill, к тому же, может быть недоступен.

Re: /var/log/messages

>Смею заметить, что между `mv` файла и SIGHUP’ом тоже возникает риск потери информации, т.к. syslog пишет в уже удаленный файл — точно такой же, как и в моем примере.

Источник

Лог файлы Linux по порядку

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

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

Основные лог файлы

Все файлы журналов, можно отнести к одной из следующих категорий:

Большинство же лог файлов содержится в директории /var/log .

• /var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
• /var/log/auth.log или /var/log/secure — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
• /var/log/dmesg — драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ —level= можно отфильтровать вывод по критерию значимости.

• /var/log/alternatives.log — Вывод программы update-alternatives , в котором находятся символические ссылки на команды или библиотеки по умолчанию.
• /var/log/anaconda.log — Записи, зарегистрированные во время установки системы.
• /var/log/audit — Записи, созданные службой аудита auditd .
• /var/log/boot.log — Информация, которая пишется при загрузке операционной системы.
• /var/log/cron — Отчет службы crond об исполняемых командах и сообщения от самих команд.
• /var/log/cups — Все, что связано с печатью и принтерами.
• /var/log/faillog — Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog .
• var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
• /var/log/maillog/ или /var/log/mail.log — Журнал почтового сервера, используемого на ОС.
• /var/log/pm-powersave.log — Сообщения службы экономии заряда батареи.
• /var/log/samba/ — Логи файлового сервера Samba , который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
• /var/log/spooler — Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
• /var/log/Xorg.0.log — Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.

Для каждого дистрибутива будет отдельный журнал менеджера пакетов.

• /var/log/yum.log — Для программ установленных с помощью Yum в RedHat Linux.
• /var/log/emerge.log — Для ebuild -ов установленных из Portage с помощью emerge в Gentoo Linux.
• /var/log/dpkg.log — Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.

И немного бинарных журналов учета пользовательских сессий.

• /var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой last .
• /var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2 .
• /var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
• /var/log/utmp — Список входов пользователей в систему на данный момент.
• /var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump .

И другие журналы

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

• /var/log/mysql/ — Лог базы данных MySQL.
• /var/log/httpd/ или /var/log/apache2/ — Лог веб сервера Apache, журнал доступа находится в access_log , а ошибки — в error_log .
• /var/log/lighthttpd/ — Лог веб сервера lighttpd.

В домашнем каталоге пользователя могут находится журналы графических приложений, DE.

/.xsession-errors — Вывод stderr графических приложений X11.

/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

Чем просматривать — lnav

Почти все знают об утилите less и команде tail -f . Также для этих целей сгодится редактор vim и файловый менеджер Midnight Commander. У всех есть свои недостатки: less неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор vim понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью .

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.

Установка пакета как обычно одной командой.

Навигатор журналов lnav понимает ряд форматов файлов.

• Access_log веб сервера.
• CUPS page_log
• Syslog
• glog
• dpkg.log
• strace
• Произвольные записи с временными отметками
• gzip, bzip
• Журнал VMWare ESXi/vCenter

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

Программа умеет напрямую открывать архивный файл.

Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу . Это с моего syslog-а.

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

Источник

Удалить все /var /log?

Можно ли удалить все в /var/log ? Или я должен только удалять файлы (рекурсивно) в /var/log , но оставить папки?

Есть ли у кого хорошая строка rm ? (Мои навыки администратора оставляют меня нервным.)

Примечание. Я использую Debian. Я не уверен, какая версия.

9 ответов

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

Вы никогда не знаете, когда вам понадобятся журналы с некоторого времени назад, поэтому лучше их архивировать (до разумного возраста, например, 3 месяца).

logrotate может сжать ваши старые файлы журналов, чтобы они не занимали много места на диске.

Если вы удалите все в /var /log, вы, скорее всего, получите массу сообщений об ошибках за очень короткое время, так как там есть папки, которые, как ожидается, будут существовать (например, exim4, apache2, apt, cups, mysql, samba и др.). Плюс: есть некоторые службы или приложения, которые не будут создавать свои файлы журналов, если они не существуют. Они ожидают по крайней мере пустого файла. Поэтому прямой ответ на ваш вопрос на самом деле — «Не делай этого . » .

Как отметил Йоши, для этого нет оснований. У меня запущены серверы debian, у которых не было одного файла журнала, удаляемого за многие годы.

Удалить все файлы:

Удалить все .gz и повернутый файл

Попробуйте запустить команду без «-delete», чтобы протестировать ее.

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

Читайте также:  Postgresql бэкап по расписанию windows

, который очищает журналы, но сохраняет файлы.

Очистка всех журналов в системе Linux без удаления файлов:

Samba ( /var/www/samba ) создает имена файлов журналов с IP-адресами, вы можете их удалить:

Вы можете использовать параметр ctime для поиска старых файлов . например:

Как bindbn объясните, сначала попробуйте найти файлы выборки и после использования опции delete: D

Я использовал простой уборщик здесь:

• Удаляет имена файлов с помощью следующих шаблонов имен файлов с паролями в /var/log
  ^.*/.+\.[[:digit:]]+(\.[[:alpha:]]+)?$ литий>
  • ^.*/.+\.old$ (без учета регистра)
• Truncate /Empty файлы с именами файлов со следующими шаблонами имен файлов в /var/log
  • ^.*/.+\.log$ (без учета регистра)

/var/log часто имеет разрешения drwxrwxr-x , поэтому он не доступен для пользователя, если только пользователь не является root или принадлежит привилегированной группе. Это означает, что новые файлы журналов не могут быть созданы не-привилегированными пользователями.

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

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

Итак, что происходит, если файл журнала и путь к файлу журнала не существуют? Это полностью зависит от приложения. Некоторые приложения будут спокойно пропускать протоколирование. Другие создадут много предупреждений. И другие просто выручат. Там нет жесткого правила; это зависит от бдительности разработчика приложения, а также от того, насколько критичен разработчик его способность регистрироваться. В лучшем случае приложение попытается либо написать, либо, возможно, создать, а затем записать в файл журнала в месте назначения в /var/log и будет не может этого сделать, потому что он запускается пользователем, который не имеет прав на запись в эту часть файловой системы.

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

Соответствующее действие — установить logrotate с соответствующими конфигурационными файлами. Обычно вращение будет связано с заданием cron. Вращение может быть основано на интервалах, или на основе размера, или и то, и другое. Также возможно настроить правила, которые не допускают поворота на основе интервалов, если файл журнала по-прежнему пуст, когда истекает интервал. Вращение может включать в себя рассылку лог-файлов, сжатие, удаление, измельчение и т. Д.

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

Источник