systemd 256

В таком случае чем плох, например, openRC, авторы которого не работают в Microsoft который позиционируется именно как инит на замену классическому SysV init и не пытается затащить в себя всё, начиная от загрузчика и кончая сетевым менеджером?

Если она сдохла мне насрать на журнал. Если она скомпрометирована, журналу в любом случае нельзя верить.

Он сдох. Если хочется альтернативы, есть dinit. У него как-то больше шансов.

Если она сдохла мне насрать на журнал.

Восстанавливать наугад будешь?

Если она скомпрометирована, журналу в любом случае нельзя верить.

Удалённому — можно. Потому что в него после взлома полетит и то что лог на удалённой машине очищен, и IP взломщика. И с этим взломщик сделать ничего не сможет. Разве что попробует засрать логи в надежде на ротацию на удалённом сборщике логов.

Восстанавливать наугад будешь?

Что значит наугад? Либо сдохло железо, либо кто-то сделал аналог rm rf. В обоих случаях логи не помогут ничем.

Если сервер загружается, я посмотрю в логи. Проблемы нет.

Удалённому — можно. Потому что в него после взлома полетит и то что лог на удалённой машине очищен, и IP взломщика.

Все эти вещи замечает мониторинг еще на этапе атаки. Либо не замечает, и тогда логи тебе уже тоже ничем не помогут.

P.S. Тем не менее, тебе ничего не мешает релеить логи журнала по любому удобному тебе протоколу.

программисты которого застряли в прошлом

Вариант застрять в прошлом вместе с ними и не обновлять systemd доступен всем желающим совершенно бесплатно.

появятся новые профессии с приставкой systemd

Эта профессия называется «системный администратор». Впрочем тебе её всё-равно не осилить.

какая проблема контейнеризировать или позапихать в виртаульные машины старый софт?

проблемма что ентим надо заниматься: сначала переделать, потом доделать, вычистить косяки, уточнить моменты реализации.
даже просто переписать скрипты на юнит - это ж цельна работа с этапами изучения, вчитывания в тонкости. а нахрена если все и так работало. ты хошь штоп бодоратый по самые пятки админ как студентиос изучал новую систему ??
на**й !! проще пердеть из своего угла, что все новье адназначно говно и подстилки молью проеденной, по имени сис5, не стоит никак.
:)

Либо сдохло железо, либо кто-то сделал аналог rm rf.

Ну то есть наугад. Всё с тобой понятно.

Все эти вещи замечает мониторинг еще на этапе атаки. Либо не замечает, и тогда логи тебе уже тоже ничем не помогут.

Мониторинг это НЕ замена логгированию! Вообще никак.

Ну то есть наугад. Всё с тобой понятно.

Ну ты можешь попытаться привести пример того, как логи упростили тебе post-mortem сервера от железных причин.

Мониторинг это НЕ замена логгированию! Вообще никак.

Логирование это не замена мониторингу, что ты пытаешься сделать. Ну и ты пропустил ту часть, где journald умеет релеить сообщения в syslog, а любой релей, который хочет релеить из journald, может это сделать. Просто читаешь из журанала и шлешь в сокет. UNIX way из всех щелей!

Systemd же пытается решить не только задачу консистентного запуска всего и вся, но и создания инфраструктуры для всех прикладных процессов. Какая разница, чем поднимать тот же rsyslog и dbus, если в системных сервисах в пространстве пользователя единообразия не будет? Получается, что каждый прикладной процесс должен решать для себя примерно следующую задачу: о! Меня подняли юнитом systemd, надо проинитить мой dbus-интерфейс и отдаться под управление systemd. А если не из-под systemd, то два раза форкнуться как учили и установить обработчик sighup для возможного рестарта с обновлением конфигурации. Тут как раз получается, что чем поднимать юзерспейс примерно все равно, а вот что дальше? Сколько было тех же автомаунтеров и системных шин? Корба-не корба, потом еще что-то... Или еще что-то до корбы было? Теперь вот dbus с udevd. Вполне удачное сочетание.

Как бы, я пытаюсь вытащить из этого всего что-то разумное. Пока примерно понятно, что происходит с развитием systemd, но не очень понятно, где они остановятся.

Ну то есть наугад. Всё с тобой понятно.

Ну ты можешь попытаться привести пример того, как логи упростили тебе post-mortem сервера от железных причин.

У меня дома был 1U, и он иногда вис наглухо, да так, что только принудительный ребут мог его оживить. Попробуй диагностировать проблему по этим вводным. ☺ А потом я может быть расскажу причём здесь RFC3164. ☺

Ну и ты пропустил ту часть, где journald умеет релеить сообщения в syslog, а любой релей, который хочет релеить из journald, может это сделать. Просто читаешь и шлешь. UNIX way из всех щелей!

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

У меня дома был 1U, и он иногда вис наглухо, да так, что только принудительный ребут мог его оживить. Попробуй диагностировать проблему по этим вводным. ☺ А потом я может быть расскажу причём здесь RFC3164. ☺

crash kernel, который запишет весь dmesg, а не только тот, который успел отправить. А успевает он отправить ваще далеко не весь, особенно когда зависает. Помимо dmesg он запишет состояние процессов, релевантные куски памяти и прочее, что нужно программистам ядра для отладки. Это я тебе как программист ядра, который это отлаживал, говорю.

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

Ну как бы rsyslogd это и делает.

Ну если только в этой системе инициализации не отломают поддержку systemV-style демонов. У них же теперь и демоны надо писать совсем по-другому

Ну если только в этой системе инициализации не отломают поддержку systemV-style демонов. У них же теперь и демоны надо писать совсем по-другому

Прочитал сейчас в daemon(7) как запускаются SysV-style демоны. Там вроде бы нет ничего, что завязано на систему инициализации, а только вызовы обычного POSIX API. Всего 15 пунктов, против 12-и у «нового пути». То есть проблемы могу быть лишь у systemd демонов, разворачиваться в неродном для них systemd-free мире, но не наоборот.

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

journald, вообще говоря, прекрасен.

Полностью поддерживаю.

Очень удобно что все сразу по юнитам распихано.

Это же только для системного, для пользовательских юнитов оно не работает?

Я много думал об этом

Чем?

в итоге теперь работает в M$

Гентушникам про это расскажи, клоун.

Это же только для системного, для пользовательских юнитов оно не работает?

Работает. journalctl -u.

Прочитал сейчас в daemon(7) как запускаются SysV-style демоны. Там вроде бы нет ничего, что завязано на систему инициализации, а только вызовы обычного POSIX API. Всего 15 пунктов, против 12-и у «нового пути». То есть проблемы могу быть лишь у systemd демонов, разворачиваться в неродном для них systemd-free мире, но не наоборот.

Лулз в том, что daemon() это только половина веселья. Стандартная проблема лялексовых сервисов до шиштемд – сервис падает до того, как шлет что-то в сислог, логов нет, есть stderr, который никто никуда не пишет.

crash kernel, который запишет весь dmesg, а не только тот, который успел отправить. А успевает он отправить ваще далеко не весь, особенно когда зависает. Помимо dmesg он запишет состояние процессов, релевантные куски памяти и прочее, что нужно программистам ядра для отладки. Это я тебе как программист ядра, который это отлаживал, говорю.

Проблема была в откисании одного сокета от перегрева. И в отправленных логах это было видно.

Ну как бы rsyslogd это и делает.

Тогда зачем лишняя прослойка в виде journald с его бинарными логами? ^_~

Проблема была в откисании одного сокета от перегрева. И в отправленных логах это было видно.

И это так же было бы видно в логах на хосте, раз он грузился. И в dmesg от crash kernel, который должен был сработать на панику от локапа (ведь ты не наркоман постоянно руками ребутать сервер, когда за тебя это может сделать watchdog?). Разница-то где?

Тогда зачем лишняя прослойка в виде journald с его бинарными логами? ^_~

Затем, что мне некуда отправлять логи с моего ляптопа.

Как вы умудряетесь в этом разбираться

Как и всегда - читаем документацию (настолько качественных доков как у systemd я, к сожалению, ни в одном открытом проекте не видел) и понимаем её.

и зачем

Чтобы оставаться профессионально релевантным, а то можно превратиться в позорного «вытирана юникса» и бегать по форумам с пылающим пердаком.

Как и всегда - читаем документацию (настолько качественных доков как у systemd я, к сожалению, ни в одном открытом проекте не видел) и понимаем её.

Ну похожая по качеству есть у openbsd, но среди слюниксовых проектов разве что util-linux.

В первую очередь он «прекрасен» тем, что не совместим ни с RFC3164, ни с RFC5424

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

В таком случае чем плох, например, openRC

Примерно всем - там даже параллельный старт сервисов годами запилить не смогли. А уж по функциональности он даже 10% возможностей systemd не покрывает. Именно поэтому openRC используют исключительно маргинальные дистрибутивы.

Ну еще юниты должны знать, что они запускают или перезапускают SysV-style демон. Типа kill -SIGHUP не забыть. А у systemd демонов, да проблем много. И заметьте, это все «пока в очередной раз не отломали» :)

я для сбора логов с роутера, умеющего выхлоп только в сислог-порт прикручивал програмку с гитхаба. работало.

Лулз в том, что daemon() это только половина веселья. Стандартная проблема лялексовых сервисов до шиштемд – сервис падает до того, как шлет что-то в сислог, логов нет, есть stderr, который никто никуда не пишет.

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

Да и бросаться переписывать все под шиштемд лично у меня времени нет. :)

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

Нет, не криво. Он этого конфига мог не найти, мог сдохнуть линкер, он мог сдохнуть на выделении ресурсов, что угодно могло случиться.

Да и бросаться переписывать все под шиштемд лично у меня времени нет. :)

переписывать все

А что переписывать-то? шиштемд умеет трекать процессы, запущенные через fork.

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

И это так же было бы видно в логах на хосте, раз он грузился.

Ага, вот только для начала его нужно включить. И существуют аппаратные проблемы, при которых включение только добьёт железку.

Разница-то где?

В деталях.

логи с моего ляптопа

Ясно-понятно, админ локалхоста мне вещает про нужность RFC… Иди лесом, пожалуйста, и больше не возвращайся.

Читаю. Пока что «кровавая бюрократия» и «сами виноваты», конкретики примерно 0.

У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.

Т.е. «единственным вариантом было похоронить всё кроме виндофонов», а «можно было под благовидным предлогом прибить этот табун менеджеров», т.е. это так, побочный эффект.

Ну ладно, я согласен, здоровая и работоспособная Нокия не начала бы теряь прибыль и обороты и не попала бы под Элопа. Но это не отменяет того факта, что он «спас» кампанию методом распила. Кстати, отдав на аутсорс тот самый критически важный компонент бизнеса - разработку мобильной платфомы. И как мне кажется совершенно не воспользовавшись теми самыми плюсами кампании, которые можно было сохранить уволив весь менеджмент.

В первую очередь он «прекрасен» тем, что не совместим ни с RFC3164, ни с RFC5424

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

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

Ну я логи со своего домашнего роутера на OpenWRT собираю туда же, куда собираю логи с домашнего сервера, виртуалок и джейлов на этом сервере, десктопа и двух ноутов. У меня эксклюзивно для remote syslog стоит железка под управлением FreeBSD и собирает логи по всей домашней сети. Причём даже устанавливать ничего не нужно, этот функционал во FreeBSD искаропки! И это удобно!

Разве неплохо? Он не сделал ничего такого, чего не сделали без него ничем не хуже. Если бы не административный ресурс красношапок, не было никакого смысла внедрять это. Любой крупный игрок, способный послать на 3 буквы GTK-окружения, так и сделал. И фактически 90% линукс-систем работают без системд.

О, это прекрасная вещь в себе, которая даже не может внятно сказать есть ли у него какие то логи или нету. А ещё они по умолчанию хранятся в tmpfs, что как известно крайне надёжно в случае разбора залётов после ребута.

Ага, вот только для начала его нужно включить. И существуют аппаратные проблемы, при которых включение только добьёт железку.

Учитывая повсеместные вотчдоги, ты этот кейс высосал.

Ясно-понятно, админ локалхоста мне вещает про нужность RFC… Иди лесом, пожалуйста, и больше не возвращайся.

:DDDDDDD

у меня вот дома есть молоток - он идеален чтобы бить по гвоздю. причем даже мудрить ничего не надо, все работает изкаропки.
а вот соседу плохо - у него перфоратор, им бить по гвоздю ваааще неудобно, а стоит дороже !!

Ну я о том и вещаю в контексте journald. ☺

им на замену до сих пор ничего не предложено

У них масса замен, причём как правило использующих стандартные JSON и HTTPS как, например, journal.

И фактически 90% линукс-систем работают без системд.

Вы прослушали репортаж из делирийного маня-мирка хейтеров. И ведь этот фимозный наверняка считается себя линуксоидом и никак не может понять почему над ним в голос ржут :-D

А ещё они по умолчанию хранятся в tmpfs, что как известно крайне надёжно в случае разбора залётов после ребута.

Почему у меня в арче сразу нормально? :DDDDDD

дыкыть никто не против :) как хотите так и живите…
главное не вонйте если чё не по вашему :)

главное не вонйте если чё не по вашему :)

Тут выше модераторы возмущались почему в треде про systemd за два дня не развели многостраничный срач. Люди даже попкорн приготовили. Я лишь пытаюсь исправить это досадное упущение. (=

И как много UNIX-like это поддерживают? Не стану требовать невозможного, потому про Solaris спрашивать не буду, хотя бы из RHEL, SLE, Debian это поддерживают? Желательно искаропки.