А что сейчас в linux отвечает за логи ?

Там где есть системд, используют его, там где нет, очевидно нет. Не скажу за остальных, а в opensuse 13.1 при установке rsyslog он тоже начинает собирать логи, правила из /etc/rsyslog.d работают так же как и раньше.

Как-то так:

# cat /etc/rsyslog.d/listen.conf 
$SystemLogSocketName /run/systemd/journal/syslog

syslog-ng

busybox syslogd :3

есть ли смысл в современном курсе про линукс рассказывать про логи на примере rsyslog

Без разницы, на примерах какого из популярных logging daemon рассказывать общую концепцию логирования. Но всё же, для полного курса, основы проще показать в командах journald аккуратно приводя параллели c конфигом rsyslogd и, постепенно смещаясь в сторону функциональности, показать на конфигах syslog-ng всю мощь того, что можно сделать с логами.

Там где есть системд, используют его, там где нет, очевидно нет.

Да нигде systemd-journald по умолчанию не используют. Он же почти ничего не умеет.

Logrotate не забудь, а то у всех, кто о ротации и о вынесении /var/log за пределы корневого раздела не слышал, место на корне постоянно кончается :)

Скажем, есть ли смысл в современном курсе про линукс рассказывать про логи на примере rsyslog ?

Можно, но правильно - про syslog в принципе. Всё остальное - частные случаи. включая systemd. Кстати, очередная версия syslog-ng умеет выдирать логи из systemd без его, systemd, желания. :-)

Используют-используют. Для десктопа и небольшого сервера его функциональности за глаза. А кому надо что-то навороченое, тот уже сам себе ставит не «по умолчанию».

Впрочем, ЕМНИП, в арче и syslog-ng тоже тянулся из коробки. Не проверял.

Особенно доставляет база данных journald, которая не умеет ACID, из-за чего в journald есть баг, который приводит к коррупции логов после плановой(sic!) ротации. И про которую разрабы systemd(sic!) сказали буквально следующее: это архтитектурное, поправить сейчас не сможем.

смотря что за курс. а вообще нет особого смысла. просто дать представление. кому надо - тот сам разберётся

Ссыль можно?

https://bugs.freedesktop.org/show_bug.cgi?id=64116

The only way to deal with journal corruptions, currently, is to ignore them: when a corruption is detected, journald will rename the file to <something>.journal~, and journalctl will try to do its best reading it. Actually fixing journal corruptions is a hard job, and it seems unlikely that it will be implemented in the near future.

Note that the corruption reporting has become more verbose since this bug was reported, and some «corruptions» that were reported as such are now reported as unusual, but acceptable events (happened after 204, so the changes are included in systemd-205).

Чтобы немного прояснить ситуацию: у чувака повис ляптоп. Он ребутнулся, а все его логи отротировались (но остались сохранены), потому что файл покораптился. Проблема в том, что убитый файл не проверяется чек-суммами. А значит его содержимому доверять нельзя. Например, ты можешь вломиться к кому-то на сервер, сделать чо-чо, покорежить лог-файл и все будут думать, что так и было. Что делает заявляение Поттеринга о том, что их логи более безопасны из-за подписей несколько голословным.

Так там написано, что делать с повреждёнными файлами. Но не написано, почему они повреждаются. Или я неправильно прочитал?

Например так: http://www.reddit.com/r/linux/comments/1y6q0l/systemds_binary_logs_and_corrup...

Опять же, там сказано как читать повреждённый журнал. Но почему он повреждается (кроме «я перезагрузился и оно сломалось») нет. мне интересна сама причина, по которой это происходит.

EPIC WIN!

Хорошо, что я бросил идею отказаться от rsyslog в пользу journald. Хотя это было неизбежно по причине того, что journalctl не умеет выдавать данные так, как я хочу, а journald не умеет их хранить так, как я хочу.

Потому что у них нет транзакций. Файл журнала почти что текстовый файл. И если все упало во время записи, то он будет кривым.

Разве ФС со своим журналом не решает ситуацию, когда запись в файл отвалилась внезапно?

Гм. Ты не понял. ФС остается целой, с ней всё хорошо. Файл остается недописанным. Кривая запись в файле -> коррупция. Тот же sqlite просто откатывает транзакцию назад, если видит, что она неполная. Ну и page cache, в котором ещё может быть часть данных.

А как файл может оказаться недописанным, кроме как если ФС отрубилась?

Тот же sqlite просто откатывает транзакцию назад, если видит, что она неполная.

journal просто пропускает её при попытке читать повреждённый лог. Он не весь теряется, насколько я понял. А не откатывает потому, что всякие подписи-шмодписи и инкрементальность, типа нельзя удалять старые куски лога. Но я встречал упоминание, что при чтении повреждённых лог оно может тормозить.

Смотри. Если у тебя запись идет не DIRECT, то данные сначала идут в page cache. А это верно в большей части случаев. И если не дергать sync после каждой записи, то данные на диск сбрасываются не сразу. Если в этот момент случится падение — данные потеряются. Более того, у дисков тоже есть кеш. И они тоже могут не успеть его сбросить, хотя уже ответили, что данные записали.

А насчет пропускает — он обнаруживает коррупцию и они принудительно ротируют файл. Поттеринг там об этом пишет, что это самый адекватный способ в их ситуации.

А насчет пропускает — он обнаруживает коррупцию и они принудительно ротируют файл. Поттеринг там об этом пишет, что это самый адекватный способ в их ситуации.

А как надо «по хорошему»? Удалять эту строку, и дальше работать с тем же файлом?

Насчет удалять не уверен. Я бы поместил в некий `stash', мол ребята, вот у вас тут такая херня была, а что случилось мы не поняли. Но херня была.

И подписывать только то, что гарантировано записалось. В общем, им нужен был sqlite :) Что самое смешное, rsyslog умеет базы данных. И можно было бы написать простую морду к dbms, в духе journalctl.

Что самое смешное, rsyslog умеет базы данных. И можно было бы написать простую морду к dbms, в духе journalctl.

А rsyslog умеет в их хитрое инкрементальное подписывание журналов?

Как ты видишь, их хитрое подписывание журнала мало что стоит. Я могу просто прибить записи :) Целостность всего журанала-то не гарантируется.

Так у них защита от поддельных записей, а не от удаления. А вообще да, печалька.

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

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

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

Поттерингу срочно надо изучить как работает bdb. Тогда проблем с повреждением логов не будет.

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

Это все замечательно до тех пор пока кто-то не «пофиксит» лог и допишет «естественную» поврежденную запись.

Это все замечательно до тех пор пока кто-то не «пофиксит» лог и допишет «естественную» поврежденную запись.

А смысл? Она же нигде не будет отображаться.

Почему? Что им мешает подписать запись-то? Все же локально делается, ключ рядом лежит.

Затем, что ротейт у тебя произошёл не тогда, когда нужно. А наивный админ решит «так и должно быть, кривое поделие ж». Все это к тому, что отмашка «поврежденный файл == норма» попадает в класс потенциальных уязвимостей класса соц.инженерии :)