как грамотно на линуксе сделать truncate файлу messages?

[AlexM]

%SUBJ%, с сохранением текущих данных?

[rojer]

mv /var/log/messages /var/log/messages.x && killall -HUP syslogd
дальше с файлом messages.x можешь делать что хочешь.

регулярную ротацию логов выполняет logrotate(8)

[AlexM]

Сообщение от rojer

mv /var/log/messages /var/log/messages.x && killall -HUP syslogd
дальше с файлом messages.x можешь делать что хочешь.

нет, этот способ не подходит, сообщения валятся в messages десятками в секунду...

The problem is that when you remove the /var/adm/messages syslogd gets confused and unhappy and you have to give syslogd a HUPSIG. And if you are really unlucky your system will go down because you didn't create /var/adm/messages quick enough or forgot it.

именно поэтому я спрашиваю о грамотном способе.

[alz]

Если уж у тебя такой трафик, то верх неприличия всю эту бодягу хранить в текстовых файлах Воткни syslog-ng и настрой его юзать mysql базу в качестве хранилища. Еще и веб интерфейс к этому делу прикрутить можно чтоб смотреть удобно было... Если лень, то поставь только syslog-ng и пользуй его фичу

[AlexM]

Сообщение от alz

Если уж у тебя такой трафик, то верх неприличия всю эту бодягу хранить в текстовых файлах Воткни syslog-ng и настрой его юзать mysql базу в качестве хранилища. Еще и веб интерфейс к этому делу прикрутить можно чтоб смотреть удобно было... Если лень, то поставь только syslog-ng и пользуй его фичу

поведай, а чем лучше SQL для хранения одного текстового файла? при условии, что никакого анализа/просмотра этого файла не предполагается.

[Andrew Shahoff]

Зачем тогда его хранить ? :D /dev/null спасёт отца ирландской демократии.

На самом деле хранение месседжа в базе позволяет чистить её раз в день не роняя syslog

[abg]

/dev/null - самый правильный файл

[alz]

Сообщение от AlexM

поведай, а чем лучше SQL для хранения одного текстового файла? при условии, что никакого анализа/просмотра этого файла не предполагается.

Для хранения - ничем. А для анализа/просмотра - всем

[rojer]

не-не-не, ребят, какой в ж.. скл? :))
объясняю.
семантика mv такова, что файл остаётся открытым.
можешь заметить, что если ты мувнул фалйл, то syslog продолжает в него писать, потому что дескриптор, к оторый он пишет, всё ещё связан с этим инодом, смена имени не приводит к закрытию файла.
потом ты даешь сислогу HUP и он сам, когда ему удобно, переоткрывает файл.
так что способ - самый что ни на есть нежный :)
ещё не знаю, где ты прочитал такую ерунду, что "your system will go down".
это фигня всё, заявляю тебе ответственно.
линуксовый syslog создаст себе файлик сам (поэтому в моей команде нет touch).
во фре он будет жаловаться, сам не создаст. необходимо делать mv && touch && kill.
но тоже если файла не будет - не смертельно, он просто ругнётся что не смог открыть файл.

[Andrew Shahoff]

на самом деле логротэйт так и делает , не парит он мозги этим , притом условие было что читать файлы потом не надо , значит HUP syslogu можна слать без боязни потерять каието данные.
А можно вопрос ? А зачем ваше тогда дёргать меесаге файл ? если но нужен для проформы , но шибко быстро растёт , то обновляите его по мере необходимости пустым файлом , типа cp blankfile /var/log/messages , не падала даже если этот файл ваше убивался, если падает то в топку такую систему

[rojer]

если содержимое вообще не интересует, то вместо mv ставим rm.
бояться, опять же, не надо: файл удаляется, но продолжает существовать пока он открыт в syslogd, потом сислог его закрывает и место реклэймится.
это более оптимальный и корректный подход, чем cp blankfile.

всё же я тут вижу ошибку. в нормальном состоянии твоя система не должна логать столько, чтобы это становилось проблемой.
если лог засирается какой-то определённой софтиной,
то имеет смысл вкурить ман на предмет понижения её вербозности.
если конфигурации логгирования в софтине не предусмотрено, то можно попробовать отфильтровать средствами самого сислога.
man syslog.conf

[AlexM]

Сообщение от Andrew Shahoff

Зачем тогда его хранить ? :D /dev/null спасёт отца ирландской демократии.

На самом деле хранение месседжа в базе позволяет чистить её раз в день не роняя syslog

хранить надо ... для большого брата...

[Andrew Shahoff]

А что за система ? Вот Free сама каждый день tgzипит логи, и хранит пару дней , хочешь забирай хочешь не трож сама сотрёт. Я думаю лубая юникс система так делает , ша посмотрю какойнить линух....

[AlexM]

Сообщение от rojer

если содержимое вообще не интересует, то вместо mv ставим rm.
бояться, опять же, не надо: файл удаляется, но продолжает существовать пока он открыт в syslogd, потом сислог его закрывает и место реклэймится.
это более оптимальный и корректный подход, чем cp blankfile.

всё же я тут вижу ошибку. в нормальном состоянии твоя система не должна логать столько, чтобы это становилось проблемой.
если лог засирается какой-то определённой софтиной,
то имеет смысл вкурить ман на предмет понижения её вербозности.
если конфигурации логгирования в софтине не предусмотрено, то можно попробовать отфильтровать средствами самого сислога.
man syslog.conf

не, данные потом могут потребоваться - я так и написал, "с сохранением данных".
важно, чтобы сообщения, которые валятся постоянно, не были потеряны во процессе mv & killall ...

[Andrew Shahoff]

А система сама не бэкапирует мессагес ? зачем это врукопашную ?
Если такие критичные логи , то это не к syslog , он вон если по нету на удп всё логит , что явно не гарантирует сохранность данных. Если критические апликухи , то пусть в свои логи пихают. Не ?