Леннарт Поттеринг (Lennart Poettering) анонсировал (http://lists.freedesktop.org/archives/systemd-devel/2012-Jan...) новый экспериментальный релиз системного менеджера systemd v38, примечательный интеграцией наработок проекта Journal, в рамках которого развивается подсистема, призванная заменить собой службу syslog и другие сопутствующие сервисы журналирования событий. Подробный обзор особенностей Journal и отличий от syslog можно прочитать в первом анонсе проекта (http://www.opennet.me/opennews/art.shtml?num=32347).
Сообщается, что работа над Journal уже близка к завершению, остаётся нереализованными лишь несколько значительных функций и недостаточно проработана документация. Наиболее заметно наличие Journal при выполнении для сервисов команды 'systemctl status', которые теперь выдаёт и последние сообщения лога для указанного сервиса. Для совместимости с классическим syslog в systemd интегрирована специальная прослойка, которая использует сокет /run/systemd/journal/s...URL: http://lists.freedesktop.org/archives/systemd-devel/2012-Jan...
Новость: http://www.opennet.me/opennews/art.shtml?num=32785
> в противном случаедаже директория с логами не фиксирована. Феерия.
В смысле? Если я правильно понял статью, то все разумно. Есть каталог /var/log/journal - пишем в него. Раздел с /var отвалился? Пишем в tmpfs в /run/log/journal.Или вы не об этом?
Да он просто фееричный аноним
А читаем откуда? А что делаем если var привалился? А с хрена ли /run tmpfs?
Пока могу ответить только на третий вопрос (про первые два спрашивайте лично у Леннарта). /run при старте системы создается с нуля (так задумано) и большинство дистрибутивов вполне логично держат его в tmpfs :).
2)он каждые 30секунд будет вопрошать не представил ли мне лик свой /var?
" journald: don't recheck /var availability more often than 30s"
> 2)он каждые 30секунд будет вопрошать не представил ли мне лик свой /var?
> " journald: don't recheck /var availability more often than 30s"/var проверяется перед сбросом в него кэша. Собсно, 30s - это ограничение на частоту сброса.
> А читаем откуда?Если есть /var - оттуда, если нет - с /run, очевидно же.
> А что делаем если var привалился?
Сбросим все из /run в /var, очевидно же.
> А с хрена ли /run tmpfs?
Сюрприз-сюрприз! http://www.opennet.me/opennews/art.shtml?num=30080
> Если есть /var - оттуда, если нет - с /run, очевидно же.Для недумающих людей - да, определённо очевидно. Т.е. если писали и в var и в run, то куска лога всегда не видим. Да, ещё в run писали-писали, да и переполнили, а из-за этого ещё и pid-файлов проcpалu.
> Сюрприз-сюрприз!
Ололо :)) Заголовок сами-то прочитали?
Тебе же сказано, оно переместит лог в /var, когда оно появится. Нечему переполнятся, ибо /var может быть не доступен только в случае аварии, а значит сервисы в штатном режиме работать не будут.
> переместит лог в /varВо-первых, нихрена оно не переместит - читай исходники. Во-вторых, даже если бы так, как сервисы, допустим, аудита, узнают что в данный момент у нас, оказывается, не весь лог, а только кусок в /run?
> Нечему переполнятся
У тебя память бесконечная?
Того, что ткнули носом в собственную глупость некоторым мало, обязательно сделать лицо коловоротом и продолжать гнуть собственную линию. Прочитай новость по ссылке, потрудись уже.
Солнце, в моём дистрибутиве никаким tmpfs в run не пахло, потому что луди которые его делали башкой думали а не задницей. Угадаешь с 3 раз или только недофедору в жизни видел?
> Солнце, в моём дистрибутиве никаким tmpfs в run не пахло, потому что
> луди которые его делали башкой думали а не задницей.Они, видимо, совсем не думали своей головой. Тупо копировали технологии тридцатилетней давности.
И действительно, зачем вся эта разработка нужна? И зачем вообще своей головой думать? Есть что копипастить - и прекрасно, можно сто лет этим жить. Мелкософт же живет, например.
> Для недумающих людей - да, определённо очевидно. Т.е. если писали и в
> var и в run, то куска лога всегда не видим.Ну, если бы journal писали лично вы - то всяко может быть.
А творение Поттеринга пишет в /run и периодически синкает его содержимое в /var. Просто и логично.> Да, ещё в run писали-писали, да и переполнили, а из-за этого ещё и pid-файлов проcpалu.
Если туда будет писать syslog - запросто. А journald следит за наличием места на разделе с логами.
В общем, перестаньте хвалиться своим фееричным незнанием матчасти.
Гармония - не тогда, когда нечего добавить, а когда нечего отнять.
Антуан де Сент-Экзюпери.Я предлагаю не создавать новый каталог journal (какая мелочь - это всего лишь еще одна директория) в /var/log/, а решительно все хранить в /LennartPotteringGreatAndTerrible - ну ведь ясно же, да? А еще лучше так:
/Lennart/Pottering/Great/And/Terrible/А я не понял, логи что бинарные? Что cat /вар/лог/абв.лог уже нельзя?
консоль администрирования, ака mmc, уже прикрутили?
sysctemctl это не то?
> sysctemctl это не то?systemctl - это консольная тулза. Адепты юниксвея™ не одобряют, им гуй подавай :)
зачем?
Ленард придумает зачем.
> консоль администрирования, ака mmc, уже прикрутили?Давно уже, называется webmin.
>> консоль администрирования, ака mmc, уже прикрутили?
> Давно уже, называется webmin.Оно уже не развивается, хоть и работает. Ajenti, если нужно рулить всеё инфраструктурой - gosa.
>>> консоль администрирования, ака mmc, уже прикрутили?
>> Давно уже, называется webmin.
> Оно уже не развивается, хоть и работает. Ajenti, если нужно рулить всеё
> инфраструктурой - gosa.Что курите ? Парни из webmin вкурсе ?
/run это же в памяти, переполнится :)
> /run это же в памяти, переполнится :)Одна из самых вкусных фич journal (по сравнению с syslog) - продуманный механизм контроля свободного места на разделе с логами. Так что переполнение не грозит :)
>> /run это же в памяти, переполнится :)
> Одна из самых вкусных фич journal (по сравнению с syslog) - продуманный
> механизм контроля свободного места на разделе с логами. Так что переполнение
> не грозит :)А что грозит, пролюбленные логи?
> А что грозит, пролюбленные логи?Пролюбленные логи - всяко лучше, чем килл всего юзерспейса по OOM.
Если вам нравится наоборот - юзайте auditd, там все строго обратно.
A чем systemd лучше OpenRC? Понимаю, что старый sysvinit уже многим надоел, хочется нового... Но почему именно systemd?
openRC помоему не сильно отличается от обычного rc... те же яйца...
systemd значительно быстрее как минимум... есть и другие вкусности.
Ты поменьше читай маркетингового бреда. Скорости по сравнению с openrc 5-10% в лучшем случае. На медленных тачках так и вообще наоборот. И какой ценой? Даже формат логов не фиксируется, а может меняться от версии к версии.
> Ты поменьше читай маркетингового бреда. Скорости по сравнению с openrc 5-10% в
> лучшем случае. На медленных тачках так и вообще наоборот. И какой
> ценой? Даже формат логов не фиксируется, а может меняться от версии
> к версии.Я пробовал и то и другое.
Хотя я и не сильно большой эксперементатор, но в моей основной Gentoo - OpenRC по умолчанию...А в Exherbo, с которой я люблю побаловаться - systemd...
Так что я не просто так говорю... я пробовал обе, и вижу разницу.
Честно говоря мне логи достаточно побарабану... я туда заглядываю раз в год :)
Не администратор я. :)
Вижу, слышу. Ты лучше секундомер померь и списочек сервисов приведи. Впрочем, после последнего заявления можно и не продолжать.
> Вижу, слышу. Ты лучше секундомер померь и списочек сервисов приведи.А вы показания секундомера и списочек сервисов привели, когда брехали про "5-10% в лучшем случае"?
> Ты поменьше читай маркетингового бреда.Ага, и далее следует типичный маркетинговый бред:
> Скорости по сравнению с openrc 5-10% в лучшем случае.
Сами себя троллите :)
> На медленных тачках так и вообще наоборот.
Да ну? На любой машине параллелизация дает неотрицательный выигрыш по сравнению с "эстафетой", просто потому, что процессор используется практически непрерывно, а не висит с ожиданием IO одной (текущей запускаемой) службы.
>Да ну? На любой машине параллелизация дает неотрицательный выигрыш по сравнению с "эстафетой", просто потому, что процессор используется практически непрерывно, а не висит с ожиданием IO одной (текущей запускаемой) службы.А теперь контрольный вопрос, на что он используется?
> неотрицательный выигрышЭто как? Выигрыш есть, но в пределах погрешности измерения?
> Это как? Выигрыш есть, но в пределах погрешности измерения?Неотрицательный - это когда больше либо равно нулю.
В некоторых случаях выигрыш бывает нулевой, в остальных - положительный, но проигрыша нет никогда.
> Да ну? На любой машине параллелизация дает неотрицательный выигрыш по сравнению с "эстафетой"Ну да. ты забываешь зависимости между сервисами - вот попробывать что-то сетевое запустить до ifconfig - он же зараза не поймет свой адрес, и не сможет забиндится куда скажут. Будем слушать inaddr-any ?
За это идет плата в виде написания скриптов запуска на "C". Ну да - это мы уже проходили - получилось Windows.
> Ну да. ты забываешь зависимости между сервисами - вот попробывать что-то сетевое
> запустить до ifconfig - он же зараза не поймет свой адрес,
> и не сможет забиндится куда скажут.Хм. Для решения такой задачи разработчики upstart/systemd/openrc давно придумали зависимости. И только в sysvinit все еще кипятят...
к счастью, это только по-вашему
управление зависимостями, в том числе каскадная активация
управление сервисами через шину и сокеты
контроль сервисов через cgroups вместо PIDов
> управление сервисами через шину и сокетыно всё теми же методами - SIGKILL/exec. Только занимается этим уже не админ, а ещё один мутный сервис.
> но всё теми же методами - SIGKILL/exec. Только занимается этим уже не
> админ, а ещё один мутный сервис.Отстрел мутных сервисов предлагаю начать с крона. А то ишь обнаглел - у админа его законные обязанности отбирает.
> Отстрел мутных сервисов предлагаю начать с крона. А то ишь обнаглел -
> у админа его законные обязанности отбирает.А вот он в systemd смотрелся бы осмысленно - удобно же когда ВСЕ настройки касающиеся (пере)запуска программ - в одном месте, а не раскиданы в десятке мест. Cron частный случай запускалки программ. По логике вещей наезжает на часть функционала запускалки программ.
> A чем systemd лучше OpenRC? Понимаю, что старый sysvinit уже многим надоел,
> хочется нового... Но почему именно systemd?Потому что openrc - это просто велосипед на тему sysvinit, с возможностью параллельного исполнения (которую не так давно добавили и в обычный sysvinit) и собственным скриптовым языком. Те же яйца, только в профиль. Попытка облагородить шаху обвесом и скамейками :)
Что касается systemd, то он не создан по образу и подобию sysvinit, а сконструирован с нуля, с тщательным планированием архитектуры и использованием киллер-фич Linux (cgroups, fanotify, autofs и т.д.), а также давно известных фич POSIX IPC (передача сокетов от одного процесса к другому, до systemd использовалась только в макосовском launchd, дает двухкратный прирост к скорости по сравнению с классической событийной моделью openrc/upstart).
И особенно приятно - службы можно настраивать и через скрипты, и через конфиги. В openrc и sysvinit, хочешь не хочешь, приходиться с простынями скриптов трахаться. А в systemd можно использовать скрипты только в тех 1% случаев, когда возможностей конфига не хватает.
openrc не перегружен функционалом, в отличие от. И, главное, его ни кто не проталкивает. Хочешь - используешь, хочешь нет.
Hurd не перегружен функционалом, в отличие от Linux. И, главное, его ни кто не проталкивает. Хочешь - используешь, хочешь нет.
Кстати, как там продвигается священная война с блоатварью?
coreutils уже раздробили по независимому проекту на каждую утилиту?
Из ядра Linux уже выкинули в юзерспейс работу с устройствами, фс и т.д.?
> Кстати, как там продвигается священная война с блоатварью?
> coreutils уже раздробили по независимому проекту на каждую утилиту?
> Из ядра Linux уже выкинули в юзерспейс работу с устройствами, фс и
> т.д.?а кто собирался coreutils дробить? его же наоборот собрали из разных кусков
> а кто собирался coreutils дробить? его же наоборот собрали из разных кусковНу как. Bloatware же. Надо, чтобы под каждую конкретную задачу был отдельный проект (ни в коем случае не пихать ls вместе с rm!). Иначе не юниксвейно же.
> Hurd не перегружен функционалом, в отличие от Linux. И, главное, его ни
> кто не проталкивает. Хочешь - используешь, хочешь нет.Minix не перегружен функционалом. И главное его никто не проталкивает.... :))
> openrc не перегружен функционалом, в отличие от.Ну, по фичам он как раз близок к systemd. Разве что поддержки сокетов и cgroups нет. Оно и понятно - разработчики openrc придерживаются технологий 80-90-х годов прошлого века, да и вообще, походу, с POSIX IPC слабо знакомы.
> И, главное, его ни кто не проталкивает.
Ну почему. openrc весьма активно навязывается и вендорлочится в генте. Как и апстарт в убунте. По принципу "лада калина - в России лучшая машина". Как-никак свое, родное, пусть и не заводится.
А остальные дистры предпочитают выбирать лучшее из существующего. Было бы странно ожидать от них иного поведения.
У тебя что то с файловой системой случилось раз sys-apps/systemd затерся
>> openrc не перегружен функционалом, в отличие от.
> Ну, по фичам он как раз близок к systemd. Разве что поддержки
> сокетов и cgroups нет.А гентушники знают, что нет?
Очередной аноним в очередной раз громко газифицировал лужу
> A чем systemd лучше OpenRC? Понимаю, что старый sysvinit уже многим надоел,
> хочется нового... Но почему именно systemd?I no longer have the time or motivation to maintain OpenRC. This is partly because I no longer use Gentoo. All bugs should be sent to them, the discussion list and the irc channel will be closed down. This trac instance will be removed after a period of time.
Стоит отметить два интересных момента:1. В анонсе автор говорит, что 38 версия является тестовой, и лучше не включать ее в релизы дистров, а только во всякие unstable/rawhide/factory, чтобы у желающих была возможность потестировать.
2. В настоящее время journald работает в основном как лог-прокси - он собирает инфу со всех источников, и форвардит ее syslogу. Впрочем, польза от него все-таки есть - например, в systemctl status для юнита теперь отображаются последние n сообщений от него. Да и с journalctl можно пока поиграться и освоиться.
> специальная прослойка, которая использует сокет /run/systemd/journal/syslog для приема сообщенийНаоборот. Через этот сокет сообщения форвардятся демону syslog. Т.е. именно он оттуда читает. А пишет туда journald.
Клёво, теперь через дырку в логгере можно делать что угодно, от гроханья этих самых логов от запуска сервисов :))
> Клёво, теперь через дырку в логгере можно делать что угодно, от гроханья
> этих самых логов от запуска сервисов :))Незнание матчасти налицо. На будущее: journald отделен от главного процесса systemd (который init).
Значит так: не знаю кому что нравится в этом гм..., но я скажу за себя. Мне НЕ нравится:- бинарные форматы данных. Это при всех условиях куда более хрупкий формат, чем текстовой. Собсно именно по этой причине (одной из) большинство сетевых протоколов делают текстовыми. И одна из причин устойчивости никсовых систем - это текст. Это что же рубить сук на котором сидишь?!!
- неоправданно жесткий и навязанный формат сообщений; логи - это инструмент не только сисадмина, но и разраба. А разрабу (да и админу тоже) нужен лог который бы гибко подстраивался под сообщения софта, а не софт который надо допиливать под ограничения лога
- завязка на systemd; Это что попытка один глюк, завязать на другой, да? Или политика партии?
Короч, мое имхо: нефиг пихать поделия Поттеринга в майнстрим. Эсперементальная ветка - самое место для этого мусора. Может со временем сообщество и сделает конфетку из этого... ну вы меня поняли.
Глупенький, в *nix есть понятие файл, а только в Windows есть разделение "текстовый" и бинарный файл. *nix в отличии от Windows не видит между ними разницы. Какая "устойчивость" и причем тут сетевые протоколы?
Прошу тебя, нет я умоляю тебя, скажи где ты взял такую дурь?! Другим же тоже охота ширнуться!
> Глупенький, в *nix есть понятие файл, а только в Windows есть разделение
> "текстовый" и бинарный файл. *nix в отличии от Windows не видит
> между ними разницы. Какая "устойчивость" и причем тут сетевые протоколы?
> Прошу тебя, нет я умоляю тебя, скажи где ты взял такую дурь?!
> Другим же тоже охота ширнуться!Т.е. например джипег в линуксе можно открыть в например vi и там будет буквами рассказано, что-же там нарисовано? Ну что за бред. Речь про бинарный формат лога. При его повреждении - хана, его ничем нне открыть и даже уцелевшие куски будут не понятны.
Нет принципиальной разницы для ОС и ФС, что в файле текст или картинка, и в том и в другом случае должна быть установлена программа для правильного чтения файла. У Windows - не так, для нее файл txt и jpg с соответственно корректными форматами внутри - принципиально разные. Тебе на информатике в школе сказали, что текстовые файлы лучше и "устойчивее" бинарных? Правильно, твоя училка была права, а какая ОС у нее на компе стояла, дай угадаю? В *nix не так!
И еще раз для медленных: если ты заставишь логгер рисовать диаграммы с сообщениями или писать голый текст для "устойчивости" и "стабильности" - разницы в *nix нет, а вот в твоём любимом Windows разница есть.
Вы в какой-такой школе учились?> Нет принципиальной разницы для ОС и ФС, что в файле текст или картинка, и в том и в другом случае должна быть установлена программа для правильного чтения файла. У Windows - не так.
Т.е. вы, как и ещё ряд клоунов, считаете что Windows - это не ОС, я правильно понимаю?
И у Windows это также, как и у всех.
> Тебе на информатике в школе сказали, что текстовые файлы лучше и "устойчивее" бинарных?
Вообще устойчивее к повреждению. Их проще восстановить и не требуются специальные программы. Напр. моё любимое: "чт* зд*с* н*п*с*н*?" прочитать сможете? А если я также (-50% информации) поиздеваюсь над JPG или RPM?
> В *nix не так!
Так. И у *nix это также, как и у всех.
>Т.е. вы, как и ещё ряд клоунов, считаете что Windows - это не ОС, я правильно понимаю?Видимо из-за вашего ультранавыка чтения лишь половины букв и домысливания остальных, у вас возникло такое ощущение. Windows это ОС, другая ОС, к ней не применима *nix логика, вот и все.
Вместо того, чтобы тратить время на решение подобных ребусов в момент поломки, мне бы хотелось быстро решить вопрос, например, при помощи восстановления данных. Прелесть бинарных форматов в том, что можно добавить избыточную информацию для восстановления.
Она добавлена в JPEG? В RPM? В логи, обсуждаемые в данной теме?Давайте уходить от абстрактных "можно". Можно ВСЁ. Вы можете подарить мне свою квартиру и все деньги, а себя укусить за задницу. "Можете", но вот станете ли? :) Вопрос риторический.
>Т.е. например джипег в линуксе можно открыть в например vi и там будет буквами рассказано, что-же там нарисовано? Ну что за бред. Речь про бинарный формат лога. При его повреждении - хана, его ничем нне открыть и даже уцелевшие куски будут не понятны.Так у него в мозгах встроенный парсер поттер-лога. Таким бесполезно что-то доказывать.
А может случиться так, что ты и текстовый не прочтешь, а может будет читалка и/или востонавливалка битых логов, а если, да кабы, то во рту бы выросли грибы и был бы не рот, а целый огород.
А можно RAID5 это поможет в обоих случаях. А можно хранить избыточные данные, используя их как информацию для восстановления, с чистым текстом такое не прокатит. Обычно ради таких вещей и, может быть, шифрования, отказываются от чисто текстового содержимого файла. Но тебе не понять, такому как ты только дай, ты не только "джипеги", ты видео будьшь через vi читать.
Так и хочется спросить: 1. Сколько раз у вас терялась часть информации файла лога? 2. Какими средствами вы его восстанавливали? 3. Эти средства применимы для бинарных файлов?Позволю ответить за вас: 1. ни разу не терялась, 2. восстанавливаются низкоуровневыми программами чтения с диска, и 3. да, применимы.
А если нет разницы, может умерите свою религиозную пылкость?
Модератор, небось?
Я спорил и доказывал пару постов назад именно то, что вы только что сказали, что нет разницы. И хотел тонко намекнуть, что лишь редактор для чтения поменяется. А мне тут бА-А-Ажественность текста над жопегом просвещают, тьфу. У меня только один вопрос, чем вас не устроила моя пылкость?!
> а только в Windows есть разделение "текстовый" и бинарный файл.Это в каком месте там такое разделение?
Вы плохо знаете FAT и NTFS, вообще не знаете историю развития 16-битных ОС от M$, займитесь уже своим образованием.
Действительно плохо их знаю, почему и спросил. А вы знаете, но наверно не расскажете, да?Помнится, в DOS для конца текстовых файлов использовался специальный символ, вроде бы 26, но это на уровне ОС, а ФС вообще до фонаря было, что сохранять. В виндах такого не помню
Он их также не знает и путает реквизит "тип файла" и содержимое файла.> ФС вообще до фонаря было, что сохранять
Так всегда было и всегда будет. И неважно какая ФС и какая ОС.
> Он их также не знает и путает реквизит "тип файла" и содержимое
> файла.
>> ФС вообще до фонаря было, что сохранять
> Так всегда было и всегда будет. И неважно какая ФС и какая
> ОС.OS/360 смотрит на вас с презрительным удивлением.
>Он их также не знает и путает реквизит "тип файла" и содержимое файла.
>> ФС вообще до фонаря было, что сохранятьУ команды copy в ОС Windows уже пронали ключи /A и /B? Или команда copy перестала быть частью системы?
Я никогда не понимал зачем они там. Всегда пишу "/b" и не заморачиваюсь. В любом случае это особенность работы данной команды, а не ФС или ОС.
Это тяжелое наследие CP/M, незаконнорожденным потомком которой является MS DOS.
"тяжёлое"? Вот то что до сих пор в Windows нельзя создать файл "aux", "con" и т.д. - это неприятно. То что на Java пишут вместо C++ - это тяжёлое. То что не все ещё осознали что бесплатный сыр только в мышеловке и на помойке (free software) - это очень тяжёлое. А единственный ключ в единственной консольной команде - мелочь.
> А единственный ключ в единственной консольной команде - мелочь.— Ой у меня файл повредился при копировании!
— Не обращайте внимание, это мелочь.Неудивительно что микрософт не может честно конкурировать на рынке, с такими то подходами к разработке программ и техподдержке.
Верно в соседней ветке сказали: "Линукс не для пользователей, а для красноглазых идиотов, которые не могут жить без зелёной консоли".С помощью командной строки в Windows уже никто ничего не копирует. А кто копирует - тот про этот ключ знает.
О чём и речь, повреждение данных пользователя - это мелочь, в терминах микрософта...
> С помощью командной строки в Windows уже никто ничего не копируетЕще как копируют - в различных батниках, которые запускает планировщик заданий. Поскольку это самый простой способ запланировать копирование какого-нибудь файла.
> Верно в соседней ветке сказали: "Линукс не для пользователей, а для красноглазых
> идиотов, которые не могут жить без зелёной консоли".
> С помощью командной строки в Windows уже никто ничего не копирует. А
> кто копирует - тот про этот ключ знает.Да, несомненно, это повод сохранять функционал, нафиг не нужный, но потенциально способный повредить данные при копировании. Логика на грани фантастики! Браво :)
А собственно где вы в моем посте такое слово "файл" увидели? Речь шла о "бинарных форматах". А они таки да - менее устойчивые к стрессовым ситуация нежели текстовые.А что до сетевых протоколов, то они действительно фактически все текстовые. И по причине устойчивости (о ней было выше) и по причине полного пофигизма к порядку бит. Есть и еще причины, но с вас довольно и этих.
В никсовых же системах текст особенно любим в силу устойчивости, легкости обработки и возможности работать с ним минимумом подручных средств.
И я не вижу большого смысла менять текст на бинарник в подсистеме обеспечивающей жизненно-важный функционал. Тут скорость и даже удобство дальнейшей обработки строго на втором месте, а на первом - живучесть.
Ну и кроме того существующая подсистема логирования отлаживалась едва ли не годами, так что можно хоть какие-то гарантии ее работоспособности давать. В противовес ей Поттеринг известен всему миру как человек выбрасывающий тонами незрелый код. И тянуть этот его код на продакш - верх безрассудства, имхо.
Если тебе дадут бинарный лог размером даже на 50% больше, чем надо на самом деле, тебе просто можно будет восстановить недостающие места, а не читать txt-огрызки.Сетевые протоколы тут совсем не причем.
>В никсовых же системах текст особенно любим в силу устойчивости, легкости обработки и возможности работать с ним минимумом подручных средств.
Бред. Не более чем в других ОС.
Мифы и легенды об устойчивости идут от оффтопика, в никсе нет разницы. Ну да, ну да, тебе придется сменить vi на другой редактор, не более, но это уже вопрос "устойчивости" твоей психики.
И про продакшн не смешите пожалуйста, никакого журналад не будет ближайшие пару лет ни в одном месте где нужна хоть сколько-нибудь стабильная система, это ежу понятно.
Еще раз. Если поврежден произвольный кусок текста, чтобы прочесть остальное (и даже чтобы отдельные выжившие фрагменты этого куска) вам не понадобится никаких специальных инструментов - открываете в редакторе и глазками читаете. Если повреджён кусок бинарных данных - чтобы это прочесть надо как-то специально изгаляться - делать понимающие этот формат утилиты устойчивыми к сбоям или делать специальные утилиты для восстановления.Я, в общем-то обычно сторонник бинарных форматов - но, блин, не для логов же, которые должны быть доступны в как можно большем количестве ситуций, особенно нештатных!
> Если поврежден произвольный кусок текстаПовреждён по каким причинам? Сбой диска? Тогда потерялся кластер (4 кб или сколько там у вас). Весь и без вариантов. Никаких "глазками" не будет.
Если повреждён человеком или программой (умышленно) - то это косяк админа по настройке прав.
Других вариантов я не вижу. И ваши тиррады - не более чем упражнения в риторике.
>> Если поврежден произвольный кусок текста
> Никаких "глазками" не будет.И кто вам это сказал ?
1. вам не понадобится никаких специальных инструментов - открываете в редакторе и глазками читаете.
2. Никаких "глазками" не будет.
3. И кто вам это сказал?Я тебе это сказал.
> 1. вам не понадобится никаких специальных инструментов - открываете в редакторе и
> глазками читаете.
> 2. Никаких "глазками" не будет.
> 3. И кто вам это сказал?
> Я тебе это сказал.Ты сказал глупость. Ты, Ваня в общем-то только глупость и можешь говорить, непонятно зачем тебе деньги платят, только лишь для замусоривания обсуждений разве что...
> Ты сказал глупость.Ваня всегда только это и делает. Видимо набирают с той же помойки что и единоросовских ботов. Такие же бездари.
Вообще то что вот это "Ваня" поддерживает Journal весьма характерно - оно ж по определению ничего хорошего линуксу не желает, ибо наёмник майкрософта для борьбы со свободным ПО.
> Вообще то что вот это "Ваня" поддерживает Journal весьма характерно - оно
> ж по определению ничего хорошего линуксу не желает, ибо наёмник майкрософта
> для борьбы со свободным ПО.Его вообще не понять. Настоящие наемники, которые против Linux стеной стоят, обычно в Поттеринга массово какашками кидаются. Оно и понятно - человек двигает Linux вперед, добавляет новые вкусные фичи. Как с таким можно смириться?
> 1. вам не понадобится никаких специальных инструментов - открываете в редакторе и
> глазками читаете.
> 2. Никаких "глазками" не будет.
> 3. И кто вам это сказал?
> Я тебе это сказал.Мне вас искренне жаль. Видимо, если в книге вырвать страничку вы её прочитать не сможете вообще, как я понимаю?
Так я ж не о винде. Ну не прочтется этот кластер - а следующий вполне. О чём и речь.
>Я, в общем-то обычно сторонник бинарных форматов - но, блин, не для логов жеНу и зря.
Все равно потребуется текстовый редактор, на системе с журналд при восстановлении нужно иметь другой редактор и всё, разницы мало.
Уже писал - разница в сложности выдергивания корректных бинарных кусков. у тектсовых логов формат примитивный, а избыточность здоровая - можно тащить хоть грепом/авком с образа вусмерть убитого раздела, выковыривая нужные сектора простейшими регэкспами. Это не говоря о том, что текстовый редактор у вас будет всегда и на любой системе - а "другой редактор" - совсем не факт.
>И про продакшн не смешите пожалуйста, никакого журналад не будет ближайшие пару лет ни в >одном месте где нужна хоть сколько-нибудь стабильная система, это ежу понятно.Это хорошо что понятно - умненький еж видимо. Очень.
А я видимо ежа глупее и мне - нет. У меня сервера на продашине под OpenSuSE 11.4 крутятся. Пока на 11.4 Но представим - о, уж0с! - заканчивается поддержка версии, я ставлю zypper'ом нуууу....допустим 12.2 (или что там к тому моменту будет?) и что я обнаружу? Неудаляемый (никак!!) systemd я увижу точно (он уже есть)! А кто поручится что я не увижу там этот новоявленный логгер?Я понимаю что мне скажут. Скажут, типа, раз продакшн - так и покупай SLES или там RHEL. Но во-первых - в ломы, а во-вторых... Млять, так ведь все для этого штатным сотрудником Red Hat и делается! Все делается не для того что бы я конфигурил сервера и писал патчи, а только для того что бы я (моя контора) платил, а кривоподельщики из RH бабло получали. Причем именно за кривые и косые ручки!! Это полный абзац, имхо!
Ну поставь себе серверную Убунту, например, раз тебя шапка пугает. Там systemd внедрять вроде как не собираются. Во всяком случае пока. Хотя это всё паника на пустом месте.
> Ну поставь себе серверную Убунту, например, раз тебя шапка пугает. Там systemd
> внедрять вроде как не собираются. Во всяком случае пока. Хотя это
> всё паника на пустом месте.Там upstart проталкивают. Те же яйца, только в профиль.
Debian тот же врядл ли переберётся на systemd в обозримом будущем. Или центос/калькулейт. Думаю, ближайшие лет 5 никакого systemd и новоявленного логгера там близко не будет.
>[оверквотинг удален]
> не читать txt-огрызки.
> Сетевые протоколы тут совсем не причем.
>>В никсовых же системах текст особенно любим в силу устойчивости, легкости обработки и возможности работать с ним минимумом подручных средств.
> Бред. Не более чем в других ОС.
> Мифы и легенды об устойчивости идут от оффтопика, в никсе нет разницы.
> Ну да, ну да, тебе придется сменить vi на другой редактор,
> не более, но это уже вопрос "устойчивости" твоей психики.
> И про продакшн не смешите пожалуйста, никакого журналад не будет ближайшие пару
> лет ни в одном месте где нужна хоть сколько-нибудь стабильная система,
> это ежу понятно.Проще починить текстовый конфиг чем бинарный журнал Windows.
Мне кажеться с логами также.
> Проще починить текстовый конфиг чем бинарный журнал Windows.
> Мне кажеться с логами также.Логи существуют только для того, чтобы их редактировать?
>> Проще починить текстовый конфиг чем бинарный журнал Windows.
>> Мне кажеться с логами также.
> Логи существуют только для того, чтобы их редактировать?Сложно спорить с людьми, которые логи видять эпизодически 2 раза в год.
Я с ними работаю постоянно и если бы новое изобретение Поттеринга хоть чуть-чуть облегчило мне жизнь я первый бы встал на его сторону.
Но его поделка грозит большими проблеммами для меня (не буду обьяснять, не поймёте если до сих пор не поняли).
> Я с ними работаю постоянноРедактируете, для корректирования отчетности?
> и если бы новое изобретение Поттеринга хоть чуть-чуть облегчило мне жизнь я первый бы встал на его сторону. Но его поделка грозит большими проблеммами для меня (не буду обьяснять, не поймёте если до сих пор не поняли).
Да, глупый Поттеринг даже и не думал, что логи надо делать редактируемыми.
Собственно вся устойчивость текстовых логов сводится к двум вещам:
1. Огромная избыточность текстового формата.
2. Возможность прочитать информацию хоть прямым доступом к секторам (но обычно так ни кто не делает).Если реализовать в бинарном формате аналогичный уровень избыточности, то он будет не менее устойчив, но вот будет ли он такой нужен?
Вот ведь в чём вопрос — а так ли жизненно необходима подсистема логгирования и действительно ли для неё требуется на столько устойчивый к повреждениям формат?
Кстати, write-only базы в этом плане обычно достаточно устойчивы и потерю части данных они могут пережить довольно спокойно.
>[оверквотинг удален]
> 1. Огромная избыточность текстового формата.
> 2. Возможность прочитать информацию хоть прямым доступом к секторам (но обычно так
> ни кто не делает).
> Если реализовать в бинарном формате аналогичный уровень избыточности, то он будет не
> менее устойчив, но вот будет ли он такой нужен?
> Вот ведь в чём вопрос — а так ли жизненно необходима подсистема
> логгирования и действительно ли для неё требуется на столько устойчивый к
> повреждениям формат?
> Кстати, write-only базы в этом плане обычно достаточно устойчивы и потерю части
> данных они могут пережить довольно спокойно.Надеюсь вы не Администратор.
> И я не вижу большого смысла менять текст на бинарник в подсистеме обеспечивающей жизненно-важный функционал. Тут скорость и даже удобство дальнейшей обработки строго на втором месте, а на первом - живучесть.По сути дела, все ваши претензии к формату journal сводятся к тому, что в случае сбоя его файлы могут превратиться в неструктурированную кашу, да?
Тогда непонятно, почему вы защищаете syslog - у него файлы являются такой же кашей изначально.
>Собсно именно по этой причине (одной из) большинство сетевых протоколов делают текстовыми.Там мотив другой - расширяемость и куча библиотек для работа с xml/json
И да, такое впечатление что ты про WBXML например не слышал>И одна из причин устойчивости никсовых систем - это текст.
Нет, главная причина в бороде
>>Собсно именно по этой причине (одной из) большинство сетевых протоколов делают текстовыми.
> Там мотив другой - расширяемость и куча библиотек для работа с xml/jsonУ вас XML головного мозга.
Где XML в HTTP, SMTP, POP3, IMAP и т.д. ?
> Где XML в HTTP, SMTP, POP3, IMAP и т.д. ?А где текст в TCP/IP поверх которого они бегают?
> Собсно именно по этой причине (одной из) большинство сетевых
> протоколов делают текстовыми.Особенно TCP/IP на котором все и держится. Такой текстовый протокол, ага.
Не передергивайте. Не стоит валить все в одну кучу: сетевые и сеансовые (и выше) протоколы все-таки весьма разные вещи.
> - бинарные форматы данных. Это при всех условиях куда более хрупкий формат,
> чем текстовой. Собсно именно по этой причине (одной из) большинство сетевых
> протоколов делают текстовыми. И одна из причин устойчивости никсовых систем -
> это текст. Это что же рубить сук на котором сидишь?!!Скажите, вы пробовали накатить systemd с journal и открыть его логи в текстовом редакторе?
Попробуйте, будете приятно удивлены - тот же текст, просто немного разбавлен бинарным мусором. Грепанью легко поддается.
В XZ сжимаются только большие объемы данных, типа дампов.> - неоправданно жесткий и навязанный формат сообщений; логи - это инструмент не
> только сисадмина, но и разраба. А разрабу (да и админу тоже)
> нужен лог который бы гибко подстраивался под сообщения софта, а не
> софт который надо допиливать под ограничения логаВот поэтому гибкий journal разделывает деревянный syslog под орех.
> - завязка на systemd; Это что попытка один глюк, завязать на другой, да?
Нет, завязывание глюков - это ваше личное дело. Здесь у нас не наркопритон и не психиатричка, так что перестаньте скулить.
Основная проблема изобретений Поттеринга - это его эго!
Взять тот же пульс, идея - избавиться от чехарды аудио в линукс - весьма благородна, НО когда его представили он был сырой, и даже когда его начали форсить он был сырой, более того он и сейчас не очень. Зато сколько пиара, пафоса и унылого форса.
Взять системд, жить с оглядкой на System V это конечно круто, но хотелось бы что-то новое, что поможет лучше использовать ресурсы современной техники, НО не с таким же остервенением....
Вот и журнал, как следствие, не его оценивают а личность создателя, а сам создатель, зачем-то пиарит преальфу недобетовну итд, итп.
Тэги: безблагодатность, опенсорц
Да там не в преальфе недобетовне дело в случае с логами, а в том, что оно defective by design, причём на кой - не ведомо. К примеру, кто ему мешал рядом с обычными текстовыми логами бинарные файлы индекса держать? Результат получил бы тот же, не ломая всё и вся и не нарываясь на потрею логов в случае крахов FS, битой памяти и тому подобных ситуаций.
Значит так, любезнейший! При крахе FS у вас будет больше проблем, нежели нечитаемось бинарных логов, в крайнем случае, то с чего вы загрузитесь, чтобы это восстановить вполне может содержать утилиту для их чтения/восстановления (выше можете почитать посты о восстановлении бинарных данных vs гадание на текстной каше). Битая память - это не проблема. FS проверяет не в битый блок ли она, часом, пишет. А если у вас винчестер хоть чем-то лучше seagate, то он сам аппаратно заремапит битое место физически.
> FS проверяет не в битый блок ли она, часом, пишет.Нет. Это делает контроллёр самого винчестера или SSD. Если что-то нельзя записать в выбранный сектор диска, то на этот сектор контроллёр делает ремап из резервной области, а сбойный помечает как "BAD", чтобы никогда не обращаться к нему. FS о таких тонкостях не знает.
Правильно спроектированную бинарь восстановить можно, кто спорит, но это уже нужны А сектора с логами с убитой вусмерть FS я вытащу хоть грепом с авком. Но суть даже не в этом - ладно, ок, допустим нам зачем-то правда нужна бинарь, причем не парсинг/анализ логов и складывание результатов в базу, а именно сразу логгинг в таком формате. Что мешало в бинари держать только индексы/расширенную информацию + позицию в стандартных лог-файлах? Чтобы продолжало работать всё, ожидающее стандартный формат? То, что об этом не подумали - очень нехороший звоночек. Если б он сказал: "вот новый логгер, у него есть вот такие-то продвинутые возможности, но если вам оно не надо - вы заметите только изменение имени демона" - никто особенно не возмущался. Если бы оказалось удобным - переползли бы на чудесный новые возможности, и лет через 8-10 можнобыло бы старьё дропнуть. Но подход "весь мир насилья мы разрушим" очень тревожит.
> логами бинарные файлы индекса держать? Результат получил бы тот же, не
> ломая всё и вся и не нарываясь на потрею логов в случае крахов FS,А что, там не используется какой-либо самосинхронизирующийся формат, который можно начать читать с произвольного места и который так или иначе вскоре самосинхронизируется и станет читаем почти как хвост текстовика?
> битой памяти и тому подобных ситуаций.
А если у вас память битая - вы можете в файловую систему записать битые структуры самой ФС для начала. Получившуюся потом вермишель даже профессионалы по восстанновлению данных задолбаются разгребать.
Именно, FS можно не поднять - но вот текстовые логи даже из этой вермишели выдернутся стандартными утилитами unix - ну максимум перловый скрипт какой понадобится для ускорения.А что о форматов - да черт его знает, может и используется. Но это новый формат - значит возможны новые ошибки, которые, разумеется, всплывут в самый неподходящий момент. А профита - никакого.
> Именно, FS можно не поднять - но вот текстовые логи даже из
> этой вермишели выдернутся стандартными утилитами unix - ну максимум перловый скрипт
> какой понадобится для ускорения.А что, разве из логов journal текстовую инфу не выдернуть? // тест на знание матчасти
> А профита - никакого.
Профит в том, что пока файл не сломан, по нему гораздо легче выполнять поиск нужных данных и статистический анализ.
А если предположить гипотетическую ситуацию, что формат побился (хотя битого гита, например, никто не видел), то на выходе получится точно такое текстовое месиво, как и в яростно защищаемом вами syslog :)
> Вот и журнал, как следствие, не его оценивают а личность создателя, а
> сам создатель, зачем-то пиарит преальфу недобетовну итд, итп.Вообще, сам Поттеринг пиаром не занимается. Он разработчик.
Пиаром и информационным шумом занимаются те, кто радуется решению наболевших проблем, а также те, кто завидует развитию GNU/Linux. Как следствие, пиар получается как позитивным, так и негативным.
А чего вы все в эту скорость загрузки упёрлись. Если нет критичных обновлений для ядра, и сервак уходит в ребут не чаще пары раз в год, то мне как-то фиолетово загрузится он за 10 секунд или за 30.По поводу Journal мысля в слух ... кто даст гарантию, что в один "прекрасный" день не поменяется формат этого самого бинарного формата. Есть у меня, к примеру, архив старых логов и нужно восстановить картину чего было год/два назад. А тута опаньки - старый формат не поддерживается. Ставь на виртуалку старый дистр, или конверти весь архив. Что-то я подозреваю с plain text таких проблем нет и не будет.
> у меня, к примеру, архив старых логов и нужно восстановить картину
> чего было год/два назад. А тута опаньки - старый формат не поддерживается.Ну взял сорец старой версии да скомпилил. И?
бгг. компилить старый софт что б прочитать логи ... шутник однако. Сколькими способами можно вытащить данные из plain text ? Хренова туча редакторов, grep, sed, awk, cat, dd <вставить название своего костыля>Сидит такой одмин, никого не трогает. Прилетает ему запрос от безопасников - а предоставте ка мне логи вон того сервера за такое-то число. Отправляем ему бинарь, а в ответ - это чо за хрень и как мне её открыть под моей любимой win/mac os/solaris/aix/openvms/bsd ? т.е. получаем ситуёвину, аналогичную проприентарным дистрам - не портабельно и не юзабельно.
>Сидит такой одмин, никого не трогает.Сейчас он тебе скажет, что логи можно конвертнуть в текстовый формат прямо на месте. Только вот смысл от поттер-лога всё равно не прибавляется.
> бгг. компилить старый софт что б прочитать логи ... шутник однако.Вы так говорите как будто умеете логи читать вообще без софта :)
>> бгг. компилить старый софт что б прочитать логи ... шутник однако.
> Вы так говорите как будто умеете логи читать вообще без софта :)Толстячок. Читалок plain-text пачки под любую платформу/ось. Иди хоть учитайся.
>Ну взял сорец старой версии да скомпилил. И?А что, Поттеринг гарантируют безпроблемную сборку под любую платформу/компилятор?
> А что, Поттеринг гарантируют безпроблемную сборку под любую платформу/компилятор?Разработчики iptables, между прочим, не гарантируют собираемости их софтины под freebsd+clang. Их уже побили ногами за это?
> Разработчики iptables, между прочим, не гарантируют собираемости их софтины под freebsd+clang.
> Их уже побили ногами за это?journald/systemd настолько должен быть завязан на конкретное ядро? Не думаю, что тому есть разумные причины кроме "я не хочу (не умею?) писать переносимый код". Тем же cgroups есть достойные аналоги - например, jail.
> По поводу Journal мысля в слух ... кто даст гарантию, что в
> один "прекрасный" день не поменяется формат этого самого бинарного формата.Сейчас таких гарантий нет. journal только разрабатывается.
Но потом будут, это и ежу понятно. Например, на формат конфигов systemd и его API уже дано interface stability promise.
Что касается формата journal, то он имеет лишь фиксированный костяк (набор обязательных полей), все остальное можно перекраивать на усмотрение авторов конкретных служб. Так что вопросы - к ним.
Кстати, в syslog всегда было ровно то же самое. Разработчик демеона всегда мог поменять формат сообщения. И ничего, жили как-то :)
> Например, на формат конфигов systemd
> и его API уже дано interface stability promise.Т.е. не будут менять INI-мегаформат? Ну зашибись обещание.
Оно как-то страхует от того, что с появлением в ядре новой крутилки для процессов - появятся в конфиге цать ключей вида MyNewCoolProcessLimit? А-ля LimitDATA и т.п. Формат конфига ведь не меняется, верно?
Советую всем взглянуть на мнение автора rsyslog
http://bb.comp-house.ru/comp-house.repo/wiki/journald-and-rs...
Опять-двадцать пять, больше обсуждение личности Леннарта, нежели журналад. Ценно было узнать, что внутренне журналд будет чем-то похож на Windows Event Log, это явно плюс. Ведь столь мощная система с возможностью интегрироваться с другими журналами - это хорошо. При правильном наборе утилит, Леннарту придется потрудиться, можно решить проблемы, с которыми столкнулись разработчики Windows Event Log. Однако этот Леннарт очень любит черный самопиар, фактически это мы уже поняли, но без этого антуража журналд и системд был бы нам более не нужен чем сейчас.Честно признаться, масло в огонь еще и GNOME подливает. Мне кажется Red Hat и его тусовка хочет изменить linux, не скажу, что это плохо, скорее наоборот, но попки рвутся уже сейчас.
> Опять-двадцать пять, больше обсуждение личности Леннарта, нежели журналад.Т.е. полностью текст ниасилил, верно?
Вот больше технических аргументов (и, как обычно, советую прочитать оригинал):
http://bb.comp-house.ru/comp-house.repo/wiki/what-i-dont-lik...Там и про "безопасность" им. Леннарта и про мифы о syslog, которые тот выдает за недостатки последнего.
Все проекты этого "творца" - сугубое NIH. Нужно действительно разобраться в существующих решения и дополнить их, улучшить своими патчами. Но нет, для подобного нужно быть действительно квалифицированным программистом: наше стандартное решение - это написанный с нуля велосипед.
>> Для эмуляции поведения "tail -f" предусмотрена опция "-f"не понравилось: нарушает принцип kiss... имхо
> не понравилось: нарушает принцип kiss... имхоВ каком месте?