Леннарт Поттеринг, возглавляющий разработку системного менеджера systemd, прокомментировал (https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...) ситуацию, сложившуюся вокруг ошибки 1073433 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1073433) в Upstart, приводящей к повреждению корневой файловой системы в процессе выключения компьютера. При этом он рассказал о причинах и механизмах возникновения проблемы, указал на метод ее решения, и предупредил о вопросах, которые в обозримом будущем останутся нерешенными из-за ограничений архитектуры Upstart.
Чтобы обеспечить корректное состояние корневой файловой системы на момент выключения компьютера, система инициализации должна предварительно смонтировать ее в режиме «только для чтения». Чтобы ядро позволило выполнить данную операцию, на корневом разделе не должно оставаться ни одного файла, открытого на запись. Традиционно, это требование обеспечивается путем предварительной остановки всех процессов, кроме самого init, который сам по себе не держит открытых для записи файлов. Однако в некоторых ситуациях такой подход оказывается неэффективен — несмотря на то, что в системе остается только процесс init, не имеющий открытых на запись файлов, ядро все равно не позволяет перемонтировать корень только для чтения.
Дело в том, что существует еще одно ограничение, действующее даже для файлов, открытых только для чтения. Если в то время, когда файл оставался открытым на чтение для некоторого процесса, этот файл был перезаписан целиком (удален и создан заново), процесс продолжает работать со старой версией файла, и файловая система будет ждать завершения этого процесса, чтобы окончательно удалить старый файл. На данном этапе, перемонтировать систему только для чтения нельзя. Подобная ситуация происходит в том числе и при обновлении исполняемого файла init, а также библиотек и других файлов, которые используются этим процессом.
Наиболее очевидное и, казалось бы, действенное решение — перезапускать процесс init (командой «telinit u») после каждого обновления соответствующих пакетов. Однако оно далеко не всегда является эффективным — существуют ситуации, когда выявить зависимости процесса init от библиотек весьма проблематично (например, при использовании NSS или аналогичных API для плагинов). Кроме того, проблема не ограничивается только библиотеками — например, она может затронуть и файлы системной локали. И наконец, далеко не всегда перезапись файлов связана с обновлением — например, процесс prelink тоже перезаписывает файлы библиотек.
Корректным решением проблемы является перезапуск процесса init при каждом выключении, непосредственно перед попыткой перемонтирования корня. Именно по этой причине, еще во времена SysV init в RHEL и Fedora, в их скриптах выключения присутствовала команда «telinit u». Таким же путем Поттеринг рекомендует пойти и разработчикам Upstart (которые пренебрегли (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1073433...) его советом, всецело положившись не перезапуск init только при обновлении библиотек — недостатки такого шага описаны выше).
К слову сказать, в systemd данная проблема решена более изящно — вместо повторного запуска полноценного init со всеми сопутствующими библиотеками, запускается простой и компактный бинарный файл systemd-shutdownd, не использующий дополнительных зависимостей и действующий по примитивному, но надежному алгоритму: убиваются оставшиеся процессы, отмонтируются/перемонтируются оставшиеся файловые системы, отключаются loop-устройства, отключаются устройства подкачки, останавливаются устройства Device Mapper (RAID, LVM, LUKS и т.д.).
Разумеется, могут существовать целые стеки таких технологий, не позволяющие закончить за один проход (например, файловая система или раздел подкачки в loop-устройстве, использующем файл на одном из обычных разделов), поэтому shutdownd повторяет цикл снова и снова, пока остаются файловые системы, примонтированные для записи. Такой подход позволяет оставить систему гарантированно консистентной, независимо от сложности используемых технологий хранения.
Кроме того, существует еще одна проблема, связанная со сложными технологиями хранения. Дело в том, что даже примонтированная только на запись корневая файловая система не позволяет корректно остановить блочное устройство, на котором она расположена. Если это обычный раздел на диске, такое и не требуется. Однако существуют и более сложные технологии, например, RAID и iSCSI. Несоблюдение правил корректной остановки сложного и/или сетевого устройства может привести к потере данных или повреждению метаданных. Но как отмонтировать корень, если с него запущен процесс, отвечающий за размонтирование?
Это ограничение можно обойти, если на финальной стадии запускать код для отмонтирования не с корня, а из виртуальной файловой системы, например, из образа initrd, антисимметрично тому, как это происходит при запуске системы (когда init из initrd монтирует корень и передает управление процессу init из него). Подобный подход, позволяющий корректно остановить все блочные устройства, в настоящее время реализован пока только в связке systemd и dracut (dracut — модульный конструктор initrd, используемый в Fedora и openSUSE).
Примечание: Интересно, что проблема перемонтирования корневой файловой системы, похоже, присутствует не только в Upstart, но и в OpenRC — там она выражается в зависании процесса выключения с сообщением «failed because we are using / (https://www.google.com/search?q=%22failed%20becaus...)», например, после запуска prelink. Несмотря на то, что разработчики OpenRC отмечают (https://bugs.gentoo.org/show_bug.cgi?id=430318) такие ошибки, как UNCONFIRMED, опытные пользователи Gentoo знают о проблеме, и рекомендуют добавлять команду «telinit u» в скрипт выключения ОС — /etc/init.d/mount-ro.URL: https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...
Новость: https://www.opennet.ru/opennews/art.shtml?num=38943
>Леннарт Поттеринг, возглавляющий разработку системного менеджера systemd, прокомментировал ситуацию, сложившуюся вокруг ошибки в UpstartМинутка рекламы, не переключайтесь.
перестал читать после первых 2х слов
Ведение войны заключается в том, чтобы предоставлять противнику действовать согласно
его намерениям и ТЩАТЕЛЬНО ИЗУЧАТЬ их; затем сосредоточить все его внимание на чем-нибудь
одном и убить его полководца, хотя бы он и был за тысячу миль. Это и значит уметь искусно
сделать дело.Сунь-цзы. © Made in China.
Дожили. http://ru.wikipedia.org/wiki/%D0%A1%D1%8...,_%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B0%D0%BD%D0%B4%D1%80_%D0%92%D0%B0%D1%81%D0%B8%D0%BB%D1%8C%D0%B5%D0%B2%D0%B8%D1%87зыж
«Истинное правило военного искусства, — учил Суворов, — прямо напасть на противника с самой чувствительной для него стороны, а не сходиться, робко пробираясь окольными дорогами… дело может быть решено только прямым смелым наступлением».«Русские прусских всегда бивали, что ж тут перенять?», «Пудра не порох, букля не пушка, коса не тесак, и я не немец, а природный русак».
«не проиграл ни одного сражения, причем все они были выиграны при численном превосходстве неприятеля» (более 60 сражений)
ззыж
«приятно быть русским в такое славное для России время». (Петрушевский А. «Генералиссимус князь Суворов» 1884 г. С-Петербург, т.3, с.182-184).
> князь Суворов» 1884 г. С-Петербург, т.3, с.182-184).W://Искусство_войны
""долгое время датировался концом VI — началом V века до н. э.
Кто победил, кит или слон?
Боюсь в тайге Сибири они оба долго не протянут.
Это к вопросу «у(естност)и».
/«у(естност)и»/«у(местност)и»
А ядерная ракета испаряет на...й все и вся совершенно независимо от made in :).
От made in зато зависит, долетит она до "всего", или нет.
Это фатальное заблуждение предполагать, что ядерная ракета не зависит made in :D
Большинство уверено, что ядерный заряд жахнет в полную мощь, если его просто подвергнуть обычному взрыву. Они вообще не в курсе, в чем состоит основная проблема создания ядрённых бомб.
Тут все как обычно. Практика единственное мерило теории. Практика китайских полководцев подсказала, что их теорией можно просто подтереться. Какой-то необразованный монгол по имени Темучин их раскатал в блин уступая во всем. И он был далеко не единственный, кто на протяжении тысячелетий жестко дрючил китайских титеретиков.
Если бы Вы разбирались в истории Поднебесной, то Вы с удивлением заметили бы, что передернули.
> Если бы Вы разбирались в истории Поднебесной, то Вы с удивлением заметили
> бы, что передернули.Толераст? Уважай всех кромя своих сородичяй?
Совсем больной...
> ... Какой-то необразованный монгол по имени Темучин их раскатал в блин уступая во всем.
> И он был далеко не единственный, кто на протяжении тысячелетий жестко дрючил китайских
> титеретиков.И в какой жопе сейчас Монголия? :)
> перестал читать после первых 2х словПравильно. А то ведь прочитаешь - потом осуждать нельзя будет.
Зря. Перевод просто шикарен. Много полезной информации. Лёня, как всегда, не упустил шанс потроллить =)
> Зря. Перевод просто шикарен. Много полезной информации. Лёня, как всегда, не упустил
> шанс потроллить =)ты знаешь, если «тролль» не отличим от идиота, то совершенно не важно, идиот ли он «где-то там в своей глубине».
> «тролль» не отличим от идиота, то совершенно не важно,
> идиот ли он «где-то там в своей глубине».Ты эта, чьих будешь? С такими сравнениями на наше болото не заходи.
а я не тролль, я честный дурак. просто на фоне «интеллектуального большинства» выгляжу умным.
>просто на фоне «интеллектуального большинства»Так, пацаны! Клиент с первого раза не понял. Всем запомнить эту косоглазую харю в передничке, пойдёт нашим перелеском, всем запомнить, за ним должок. >/<
так я ж без маскировки не пойду. фиг вы меня узнаете в чепчике и с усами… упс.
> Зря. Перевод просто шикарен. Много полезной информации. Лёня, как всегда, не упустил
> шанс потроллить =)Пусть на наше болото заскочит, там поглядим, каков он "троль". Фабрикует весьма незатейливо, хотя бейт из него [самого] знатный. На наживку сойдёт.
Пеар systemd в надежде попасть в дебиан?
Как же сможет systemd прожить без deb?
Угу Debian'у он особо то и не нужен, особенно если учитывать что Systemd - наглухо прибит напрочь заржавевшими гвоздями к ядру Linux. Что же прикажите делать тогда с остальными ядрами Debian (Hurd,kFreeBSD,kNetBSD) ??
> Угу Debian'у он особо то и не нужен, особенно если учитывать что
> Systemd - наглухо прибит напрочь заржавевшими гвоздями к ядру Linux. Что
> же прикажите делать тогда с остальными ядрами Debian (Hurd,kFreeBSD,kNetBSD) ??Уже говорил:
https://wiki.debian.org/SummerOfCode2012/StudentApplications...
https://github.com/akhilvij/systemd-to-sysvinit-converterЕще немного:
https://wiki.debian.org/Debate/initsystem/upstart
Угу, но зачем им держать две системы инициализации в этом случае, если можно довести напильником Upstart? благо он более документирован и менее привязан к ядру Linux.
> Угу, но зачем им держать две системы инициализации в этом случае, если
> можно довести напильником Upstart? благо он более документирован и менее привязан
> к ядру Linux.Без грубостей ;) :
Может еще, Debian-щикам сбросится на очередную путевку в космос для Космонавта?
Пускай уже этот господин сделает что то полезное и для Debian (или я много кое чего не знаю в этом вопросе (наверняка))! А то вон последнее время пыль вокруг CLA поднимается, и прочее :(
И да, бронепоезд должен стоять на запасном пути. Правда его от ржавчины иногда приходится чистить (но это необходимое злощастье в придачу ;)
Ага так говорят озабоченные арчеводы и им подобные, которые дальше x86/x64 не идут, так как для них мир на этом и заканчивается. ))))В отличии от большинства дистрибутивов Debian работает на множестве платформ и множестве ядер, и он выбирает конкретные плюсы и минусы исходя из всех платформ и всех ядер.
Так или иначе SysVinit скорее всего будет заменён, иначе об этом не говорили бы ... и не ставился вопрос на собрании что выбрать Debian systemd или upstart
А зачем гента их держит?
Для мантэйнеров - больше гимора, для одминов больше гибкости.
Простите но в данном случае я за гимор для мантэйнеров и за большее количество опций для себя.
> Для мантэйнеров - больше гимораА вы майнтейнер? А геммора больше, это потратить пару часов на написание юнита/скрипта/конфига? иди даже на просмотр и мерж патча...
Я не за systemd, но каждый первый тут мнит что знает проблемы майнтейнеров...
> Угу, но зачем им держать две системы инициализации в этом случае, если
> можно довести напильником Upstart?Довольно тяжело. Он зависит от libNIH, в некоторых местах которой разбирается только Ремнант (см. соседнюю новость), который уже несколько лет как ушел из проекта.
> благо он более документирован
Неа. http://www.freedesktop.org/software/systemd/man/ This index contains 308 entries, referring to 149 individual manual pages.
Upstart нервно курит в сторонке :)> и менее привязан к ядру Linux.
Это легко поправить. Сейчас разработчики Upstart уже работают над поддержкой cgroups, а скоро и до kdbus дело дойдет.
В апстарте по самой его природе фичи жестко не прибиваются. Поэтому там cgroups и прочее - не проблема.
>> благо он более документирован
> Неа. http://www.freedesktop.org/software/systemd/man/ This index contains 308 entries,
> referring to 149 individual manual pages.при этом, поттеринг говорит: мы в документацию не успеваем, смотри в код, он первостепенней :D
> Upstart нервно курит в сторонке :)
действительно.
>> и менее привязан к ядру Linux.
> Это легко поправить. Сейчас разработчики Upstart уже работают над поддержкой cgroups, аопционально.
> скоро и до kdbus дело дойдет.
опционально.
>ри этом, поттеринг говорит: мы в документацию не успеваем, смотри в код, он первостепенней :DДа хоть бы в своём багтрэккере успевал разбираться
> Fedora 20 fails to unmount /home, /tmp and all /dev/mapper/luks- partitions on every shutdown
так вот откуда поттеринг знания почерпнул чтоб прокомментировать апстарт.
> так вот откуда поттеринг знания почерпнул чтоб прокомментировать апстарт.Скорее всего отсюда :https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1089771 (2012-12-13)
или отсюда: https://bugs.launchpad.net/upstart/+bug/1073433 (2012-10-31)
или: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/775014 (2011-05-01) (почти как три года High)и заметьте, что они Confirmed, и отписывается в треде далеко не два человека.
>> так вот откуда поттеринг знания почерпнул чтоб прокомментировать апстарт.
> Скорее всего отсюда :https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1089771
> (2012-12-13)
> или отсюда: https://bugs.launchpad.net/upstart/+bug/1073433 (2012-10-31)
> или: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/775014 (2011-05-01)
> (почти как три года High)
> и заметьте, что они Confirmed, и отписывается в треде далеко не два
> человека.может и отсюда. Понасоздают багов, и потом пиарятся на своих решениях :D
>>> так вот откуда поттеринг знания почерпнул чтоб прокомментировать апстарт.
>> Скорее всего отсюда :https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1089771
>> (2012-12-13)
>> или отсюда: https://bugs.launchpad.net/upstart/+bug/1073433 (2012-10-31)
>> или: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/775014 (2011-05-01)
>> (почти как три года High)
>> и заметьте, что они Confirmed, и отписывается в треде далеко не два
>> человека.
> может и отсюда. Понасоздают багов, и потом пиарятся на своих решениях :DАга. Лучше бы православный Патреговский юзали:
http://www.linuxquestions.org/questions/slackware-14/cryptse.../
http://www.linuxquestions.org/questions/slackware-14/large-p.../
> Ага. Лучше бы православный Патреговский юзали:
> http://www.linuxquestions.org/questions/slackware-14/cryptse.../У самого есть криптораздел и слакварь на борту. Никогда не встречал подобное. Судя по обильному количеству комментариев - не я один.
> http://www.linuxquestions.org/questions/slackware-14/large-p.../
вообще не то.
Или отсюда — https://bugs.gentoo.org/show_bug.cgi?id=493874
>sys-apps/systemd-208-r2 hangs activating encrypted swap partitionИли отсюда — https://bugs.gentoo.org/show_bug.cgi?id=486904
>Bug 486904 - (CVE-2013-4391) sys-apps/systemd : multiple vulnerabilities (CVE-2013-{4391,4392,4393,4394})…
а куда народу деваться, раз в апстримовом багтреккере systemd вообще ни ответа, ни привета.
> Или отсюда — https://bugs.gentoo.org/show_bug.cgi?id=493874
>>sys-apps/systemd-208-r2 hangs activating encrypted swap partitionI can drop the bits pointed out by Mike in #c23 from genkernel-next. I wonder why they're there in the first place, since mdev is clearly not the hotplug handler after the pivot_root in the 99% of the cases.
> Или отсюда — https://bugs.gentoo.org/show_bug.cgi?id=486904
>>Bug 486904 - (CVE-2013-4391) sys-apps/systemd : multiple vulnerabilities (CVE-2013-{4391,4392,4393,4394})Вы статус CVE-шек хоть смотрели?
> …
> а куда народу деваться, раз в апстримовом багтреккере systemd вообще ни ответа,
> ни привета.
>Вы статус CVE-шек хоть смотрели?Т.е. теперь можно сказать что их и не было?
>>Вы статус CVE-шек хоть смотрели?
> Т.е. теперь можно сказать что их и не было?Т.е. кидаться закрытыми багами как-бе нормально?
Ну бревно, вытащенное похтерингом из апстарта, ты же не заметил?
Вдруг и про уязвимости не в курсе.
External Source: CONFIRM
Name: https://bugzilla.redhat.com/show_bug.cgi?id=859060
Hyperlink:https://bugzilla.redhat.com/show_bug.cgi?id=859060https://bugzilla.redhat.com/show_bug.cgi?id=859060
> Bug 859060 - (CVE-2013-4392) CVE-2013-4392 systemd: TOCTOU race condition when updating file permissions and SELinux security contexts [NEEDINFO]
Меня этот баг настолько заипал в своё время, что я вернулся с systemd обратно на openrc.зыж
http://ru.wikipedia.org/wiki/%D0%A1%D1%8...
>«Истинное правило военного искусства, — учил Суворов, — прямо напасть на противника с самой чувствительной для него стороны, а не сходиться, робко пробираясь окольными дорогами… дело может быть решено только прямым смелым наступлением».Всё потому, чтобы «противник» не напал первым на тебя «с самой чувствительной для тебя стороны (https://bugs.freedesktop.org/buglist.cgi?quicksearch=systemd...)». :D
>>ри этом, поттеринг говорит: мы в документацию не успеваем, смотри в код, он первостепенней :D
> Да хоть бы в своём багтрэккере успевал разбираться
>> Fedora 20 fails to unmount /home, /tmp and all /dev/mapper/luks- partitions on every shutdown
> https://bugzilla.redhat.com/show_bug.cgi?id=1026119А в своем глазу значит...
https://www.mail-archive.com/debian-bugs-dist@lists.deb...
https://bugs.gentoo.org/show_bug.cgi?id=430318 (2012-08-07)
>А в своем глазу значит...хм, похтеринг сабж начал, ему дерьмо и убирать.
>>А в своем глазу значит...
> хм, похтеринг сабж начал, ему дерьмо и убирать.А-а-а! Он походу успел и в OpenRC нагадить! А мужики-то не знают )
>>ри этом, поттеринг говорит: мы в документацию не успеваем, смотри в код, он первостепенней :D
> Да хоть бы в своём багтрэккере успевал разбираться
>> Fedora 20 fails to unmount /home, /tmp and all /dev/mapper/luks- partitions on every shutdown
> https://bugzilla.redhat.com/show_bug.cgi?id=1026119Шикарно: https://bugs.gentoo.org/show_bug.cgi?id=376977
Honestly I would prefer to not use killall5 at all, but I'm not sure how
to rewrite killprocs to not use it.Мужики, это бы надо поправить, только вот хз как )
Прошло три года...
> Systemd - наглухо прибит напрочь заржавевшими гвоздями к ядру Linux.Ну не то что бы к ядру Linux, он скорее прибит гвоздями к RedHat.
> Ну не то что бы к ядру Linux, он скорее прибит гвоздями к RedHat.А также к арчу, опенсусе... в общем, половине линуксов.
к апстрим проектам, контролирующих редхат. Здесь имеется в виду компания, а не дистрибутив.
> к апстрим проектам, контролирующих редхат. Здесь имеется в виду компания, а не дистрибутив.Редхат контролируется опенсорсниками? Ну, это уже давно не тайна :)
>> к апстрим проектам, контролирующих редхат. Здесь имеется в виду компания, а не дистрибутив.
> Редхат контролируется опенсорсниками? Ну, это уже давно не тайна :)контролирует :) возможно не так выразился.
> контролирует :) возможно не так выразился.Да нет, как раз правильно.
> к апстрим проектам, контролирующих редхат. Здесь имеется в виду компания, а не дистрибутив."Лучше убью свои данные, чем поставлю проги от клятого редхата!"?
>> к апстрим проектам, контролирующих редхат. Здесь имеется в виду компания, а не дистрибутив.
> "Лучше убью свои данные, чем поставлю проги от клятого редхата!"?у меня убунта с версии 7.04. Не знаю когда там появился апстарт - но данные никогда не убивал. Не везёт.
> у меня убунта с версии 7.04. Не знаю когда там появился апстарт
> - но данные никогда не убивал. Не везёт."Я еще никогда не умирал. Значит, я бессмертен, да?"
>> у меня убунта с версии 7.04. Не знаю когда там появился апстарт
>> - но данные никогда не убивал. Не везёт.
> "Я еще никогда не умирал. Значит, я бессмертен, да?"Джо есть, просто он неуловим.
>>Ну не то что бы к ядру Linux, он скорее прибит гвоздями к RedHat.
>А также к арчу, опенсусе... в общем, половине линуксов.Скорее арч и опенсусе прибиты с помощью systemd к RedHat
/fixed
> Угу Debian'у он особо то и не нужен, особенно если учитывать что
> Systemd - наглухо прибит напрочь заржавевшими гвоздями к ядру Linux.Заржавевшие гвозди, а также ржавые цепи, погребальные саваны и загробный хохот прочно ассоциируются как раз не с Linux, а с некоторыми конкурирующими ядрами :)
> Что же прикажите делать тогда с остальными ядрами Debian (Hurd,kFreeBSD,kNetBSD) ??
Эти проекты начаты в основном от того, что людям хочется поизвращаться. Так пусть извращаются, кто ж им мешает?
> Эти проекты начаты в основном от того, что людям хочется поизвращаться.Как точно сказано про systemd.
> же прикажите делать тогда с остальными ядрами Debian (Hurd,kFreeBSD,kNetBSD) ??Оставить им инит, "на отъ...сь". Некроманам и инициализация некроманская.
> Пеар systemd в надежде попасть в дебиан?Вряд ли. Учитывая, что от обсуждения дебианщиков от откосил, сказав "у меня много работы, извините". Вместо того, чтобы убивать по полдня на опровержение FUD от Лангасека.
> Пеар systemd в надежде попасть в дебиан?Коварный план! "Срочно в номер! Red Hate передаёт systemd и Леонарда П. в проект Debian."
s/в проект/под крылошко/
> файловая система будет ждать завершения этого процессаВот интересно, каким образом в файловой системе реализовано ожидание завершения процесса?
По файловым дескрипторам - если не освобождены, значит работает
>По файловым дескрипторам - если не освобождены, значит работаетЯ про само ожидание, а не его условие.
>>По файловым дескрипторам - если не освобождены, значит работает
> Я про само ожидание, а не его условие.Очевидно драйвером FS, проверяющим условия.
>Очевидно драйвером FS, проверяющим условия.Из текста новости это не очевидно.
очевидно что процессом монтирования/размонтирования занимается драйвер файловой системы.
>очевидно что процессом монтирования/размонтирования занимается драйвер файловой системы.А завершение процесса кто ждёт?
>> файловая система будет ждать завершения этого процесса
> Вот интересно, каким образом в файловой системе реализовано ожидание завершения процесса?путём приятия героина внутрь теми, кто такое пишет. файловой системе глубоко наплевать на процессы, её интересуют только мыши^w открытые fd. как последний fd закрылся — всё, свобода.
>>> файловая система будет ждать завершения этого процессаВнимательно!^^
>> Вот интересно, каким образом в файловой системе реализовано ожидание завершения процесса?
> закрылся — всё, свобода.Он про то, что в _самой _FS ожидания нет. И его тай, и правда, нет:
# umount /
umount: /: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
# _
не думаю что это пиар. скорее заявление, которое должно показать его квалификацию. и да возможно есть желание получить бонусы от использования системд в дебиан. разработчиков то в дебиан тоже хватает.
> не думаю что это пиар. скорее заявление, которое должно показать его квалификацию.ты прав что ты неправ.
>> не думаю что это пиар. скорее заявление, которое должно показать его квалификацию.
> ты прав что ты неправ.Ну, вообще-то Ленька наглядно показал, что манагеры, пишущие upstart, не разбираются в матчасти, и поэтому их костыли не всегда работают. И, технически, он абсолютно прав.
>>> не думаю что это пиар. скорее заявление, которое должно показать его квалификацию.
>> ты прав что ты неправ.
> Ну, вообще-то Ленька наглядно показал, что манагеры, пишущие upstart, не разбираются в
> матчасти, и поэтому их костыли не всегда работают. И, технически, он
> абсолютно прав.костыли от лёньки судя по всему, systemd-shutdownd - это просто еще один бинарь для того чтоб решить проблему, решаемую через «telinit u»? Ну, простое, изящное и элегантное решение.
P.S. Все костылят, здесь ни systemd ни upstart не исключение. Действия лёни полезны для внимания апстартовцев. Пусть обе команды, конкурируя друг с другом, делают свои продукты лучше.
> костыли от лёньки судя по всему, systemd-shutdownd - это просто еще один бинарь для того чтоб решить проблему, решаемую через «telinit u»? Ну, простое, изящное и элегантное решение.То есть перезапуск инита для завершения работы - это не костыль? А простенький процесс, делающий ровно то, что нужно - это костыль?
Ваша логика мне напоминает логику МС - это они любят что-нибудь перезапустить, систему перезагрузить и т.д.
Таким как вы дай волю, так вы и реактор на АЭС перезапустите, когда нужно лампочку в сортире поменять, и еще будете потом утверждать, что это "простое, изящное и элегантное решение".
>> костыли от лёньки судя по всему, systemd-shutdownd - это просто еще один бинарь для того чтоб решить проблему, решаемую через «telinit u»? Ну, простое, изящное и элегантное решение.
> То есть перезапуск инита для завершения работы - это не костыль? А
> простенький процесс, делающий ровно то, что нужно - это костыль?
> Ваша логика мне напоминает логику МС - это они любят что-нибудь перезапустить,
> систему перезагрузить и т.д.
> Таким как вы дай волю, так вы и реактор на АЭС перезапустите,
> когда нужно лампочку в сортире поменять, и еще будете потом утверждать,
> что это "простое, изящное и элегантное решение".А чем по Вашему init должен заниматься? И почему его так страшно перезапускать?
> А чем по Вашему init должен заниматься? И почему его так страшно
> перезапускать?Почитаешь Поттера, так его просто запускать страшно -- со всеми этими перменными и отваливающимися _внешними разделами, устройствами, дин.библиотеками, локализациями и прочими независимыми зависимостями. Оно же может не взлететь в любую же секунду!! </ужосшокк>
>> А чем по Вашему init должен заниматься? И почему его так страшно
>> перезапускать?
> Почитаешь Поттера, так его просто запускать страшно -- со всеми этими перменными
> и отваливающимися _внешними разделами, устройствами, дин.библиотеками, локализациями
> и прочими независимыми зависимостями. Оно же может не взлететь в любую
> же секунду!! </ужосшокк>Да ладно, "миллион" лет уже работает и еще столько же проработает (сарказм понят ;)
Леньке наглядно объяснили, что убунта и так делает telinit u, а убивать все процессы и пытаться размонтировать фс в цикле это не лучшее решение, т.к. например если на этот момент примонтирована сетевая фс, которой все еще нужна сеть, смерть network-manager (как Леня предлагает) никак не поможет ей правильно отмонтироваться.
Локальные ФС будут размонтированы, зато сетевые будут ошибками покрываться.
Сейчас опять начнется что systemd не нужен и нафиг это поделие.
А ведь человек не только создал рабочий софт, но и не скрывает свои решения возникших проблем. Он не посоветовал что для решения проблемы возмите кусок из моего софта, или не предложил полностью на него перейти, он описал ситуацию которая возникает и описал решение которое ему показалось наиболее оптимальным и правильным. А в итоге сейчас в комментах в его адрес (да и в мой) полетят гнилые помидоры.
Я кстати довольно часто видел как в CentOS 6 не всегда может быстро и нормально при выключении отмонтироваться /var, и знаю что проблема не надуманная.
Хм, частенько видел как система не могла загрузится, потому что не проходила проверку корневая фс, потому что, fsck / выдавал ошибку о том, что / - это директория.
В большенстве случаев не разбирался, что да как, а заменял в скрипте fsck / на fsck.etx3 /dev/sda2. Да это тупо, зато на все про все 10 мин, а там уж пусть админы того сервера чешуться, а что же делать с системд в случае когда произойдет сбой во внутренней логике?Проблема в том, что идеальных решений не бывает и косячит будут и скрипты, и системд, но скрипты можно поправить, а с этим бинарным поделием, что прикажете делать? курить исходники? так может сразу нафиг?
> Хм, частенько видел как система не могла загрузится, потому что не проходила
> проверку корневая фс, потому что, fsck / выдавал ошибку о том,
> что / - это директория.Дистрибутив и версию вспомните?
> В большенстве случаев не разбирался, что да как, а заменял в скрипте
> fsck / на fsck.etx3 /dev/sda2. Да это тупо...Да, это тупо.
> Проблема в том, что идеальных решений не бывает и косячит будут и
> скрипты, и системд, но скрипты можно поправить, а с этим бинарным
> поделием, что прикажете делать? курить исходники? так может сразу нафиг?google://sytemd+debugging
> Дистрибутив и версию вспомните?RPM base, последний раз было на каком-то встроенном в систему сканирования отпечатков пальцев в отделении полиции соседнего городка, альт может быть, но точно не помню.
>> Проблема в том, что идеальных решений не бывает и косячит будут и
>> скрипты, и системд, но скрипты можно поправить, а с этим бинарным
>> поделием, что прикажете делать? курить исходники? так может сразу нафиг?
> google://sytemd+debuggingДа я даже знать не хочу как оно там работает, мне до звезды.
Скрипты помогают мне жить, я могу написать хоть в консоле последовательность действий и пойти курить пока оно выполняется, или скажем переинициализировать сеть на серваке, или помудрить с iptables, зная что через 10 мин запустится скрипт который вернет все как было, и управление я не потеряю.
А на кой черт мне отладка этого системд, я работаю в сфере эксплуатации, а не починки, как и большенство. Починкой занимаются студентики по вызову из объявлений в автобусах, но думаю даже им это нафиг не надо. Но изредка починять систему приходится, и ради этого "раз в пятилетку" - сидеть, гуглить, разбираться, да нахрен оно упало, если более мне эти знания не пригодятся, быстрее из бэкапа восстановить или заново поднять.
Какбы я не против системд на вашем компьютере, но мне это не нужно, но разрабы же не станут поддерживать оба варианта, таким образом - кто не с нами, тот против нас.
Ничего личного)))
>> Дистрибутив и версию вспомните?
> RPM base, последний раз было на каком-то встроенном в систему сканирования отпечатков
> пальцев в отделении полиции соседнего городка, альт может быть, но точно
> не помню.А в каком "скрипте" вы заменили "fsck / на fsck.etx3 /dev/sda2" вспомните? Или может быть приснилось?
P.S.: хотя бы на fsck /dev/disk/by-uuid/xxx заменили, что-ли, если уж на то пошло...
> А в каком "скрипте" вы заменили "fsck / на fsck.etx3 /dev/sda2" вспомните?
> Или может быть приснилось?
> P.S.: хотя бы на fsck /dev/disk/by-uuid/xxx заменили, что-ли, если уж на то
> пошло...https://www.linuxquestions.org/questions/other-*nix-55/checking-filesystems-failure-in-rc-sysinit-halts-boot-750842/
https://www.redhat.com/archives/libvirt-users/2013-November/...
кстате довольно распространенная проблема - преобразования /dev/root (из /proc/mounts) в /dev/[sh]dX, поэтому в большенстве дистрибутивов решалось оставить эту функцию домашним заданием fsck, который не всегда корректно ее выполнял. И именно потому, что использовались всякие - UUID=xxx или LABEL=xxx, в fstab вместо /dev/sdX.
>> А в каком "скрипте" вы заменили "fsck / на fsck.etx3 /dev/sda2" вспомните?
>> Или может быть приснилось?
>> P.S.: хотя бы на fsck /dev/disk/by-uuid/xxx заменили, что-ли, если уж на то
>> пошло...
> https://www.linuxquestions.org/questions/other-*nix-55/checking-filesystems-failure-in-rc-sysinit-halts-boot-750842/fsck.ext2: Device or resource busy while trying to open /dev/sda
Filesystem mounted or opened exclusively by another program?> https://www.redhat.com/archives/libvirt-users/2013-November/...
Guest (LXC container) : CentOS4 .8
mount: can't find / in /etc/fstab or /etc/mtabВ общем ничего даже отдаленно похожего на ваш случай...
> кстате довольно распространенная проблема - преобразования /dev/root (из /proc/mounts)
> в /dev/[sh]dX, поэтому в большенстве дистрибутивов решалось оставить эту функцию домашним
> заданием fsck, который не всегда корректно ее выполнял. И именно потому,
> что использовались всякие - UUID=xxx или LABEL=xxx, в fstab вместо /dev/sdX.Назовете это "большинство"?
>> https://www.linuxquestions.org/questions/other-*nix-55/checking-filesystems-failure-in-rc-sysinit-halts-boot-750842/
>/: clean, 155284/557056 files, 920932/2225412 blocks
> fsck.ext2: Device or resource busy while trying to open /dev/sdaтут фс на устройстве / определилась
>> https://www.redhat.com/archives/libvirt-users/2013-November/...
>fsck.ext2: Is a directory while trying to open /
>/:
>The superblock could not be read or does not describe a correct ext2
>filesystem. If the device is valid and it really contains an ext2
>filesystem (and not swap or ufs or something else), then the superblock
>is corrupt, and you might try running e2fsck with an alternate superblock:
> e2fsck -b 8193 <device>а тут нет
>[оверквотинг удален]
> тут фс на устройстве / определилась
>>> https://www.redhat.com/archives/libvirt-users/2013-November/...
>>fsck.ext2: Is a directory while trying to open /
>>/:
>>The superblock could not be read or does not describe a correct ext2
>>filesystem. If the device is valid and it really contains an ext2
>>filesystem (and not swap or ufs or something else), then the superblock
>>is corrupt, and you might try running e2fsck with an alternate superblock:
>> e2fsck -b 8193 <device>
> а тут нетНе мудрено: mount: can't find / in /etc/fstab or /etc/mtab
> Да я даже знать не хочу как оно там работает, мне до звезды.Жесть какая. Таким уникумам вообще нельзя давать в руки что-либо сложнее лома. Даже чтобы копать лопатой желательно разбираться как она работает.
> google://sytemd+debuggingбудешь на ассемблере новую логику писать? ;)
>> google://sytemd+debugging
> будешь на ассемблере новую логику писать? ;)А это к чему вообще?
>>> google://sytemd+debugging
>> будешь на ассемблере новую логику писать? ;)
> А это к чему вообще?Ну, типа намек, что юниксвей состоит в постоянном переписывании системы инициализации каждым админом под себя. А сделать одну так, чтобы она работала - нельзя, виндyзятничество.
>>>> google://sytemd+debugging
>>> будешь на ассемблере новую логику писать? ;)
>> А это к чему вообще?
> Ну, типа намек, что юниксвей состоит в постоянном переписывании системы инициализации каждым
> админом под себя.Давно уже так: sysvinit, openrc, Upstart, Runit, Daemontools, Launchd, Initng, systemd.
> А сделать одну так, чтобы она работала - нельзя, виндyзятничество.
sysvinit работала. Но делать еще одни прогрессивные плееры^W системы инициализации - типичные для кодеров действия. Bycicle, bycicle, bycicle. I want to ride my bycicle.
> sysvinit работала.initscripts: shutdown/reboot hangs after K03rsyslog
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734367sysvinit-utils: /bin/pidof fails when there are stuck NFS mount points, preventing shutdown
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719273initscripts: root filesystem is busy when it is un-mounted when doing shutdown
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463175[initscripts] umountfs: network fs should be unmounted before network-manager is shutdown
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463175
>> sysvinit работала.
> initscripts:F20: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s...
>>> sysvinit работала.
>> initscripts:
> F20: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s...Ну что же вы так однобоко: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s...,bug_status,priority,assigned_to,bug_id&query_based_on=&query_format=advanced
типа похтеринг, выступая с сабжем, проявил верх объективности?я за всю историю работы с различными системами инициализации (включая мак, солярис, юниксваре, ско опенскрвер,…) не имел столько проблем с монтированием различных ФС с не менее различных устройств, сколько за 7-9 месяцев знакомства с системд.
>> F20:
> Ну что же вы так однобоко:У него и так integer overflow случился, скорее всего.
> F20: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s...Никто и не отрицает существование багов, связанных с systemd. Я лишь хотел сказать, что и sysvinit идеализировать не стоит, проблемы бывают везде, и я привел пару примеров только чтобы об этом напомнить. Михаил, я не сравнивал ни количество багов, ни их содержание, ни между проектами, ни между дистрибутивами, я указал только на их существование. Может Вы под впечатлением от каких-то других комментов так отреагировали?
Проблемы, очевидно, бывают не только с systemd, иначе вряд ли бы кто-то упоминал простоту их решения как одно из достоинств sysvinit, что, если подумать, звучит сомнительно - пользователи предпочитают проекты, который не требует от них самих решения проблем, а просто работают, или по крайней мере оперативно решают возникающие проблемы в апстриме. Я не утверждаю, что systemd на данном этапе именно такой проект, тут вопрос в том, какой проект имеет больше шансов приблизиться к такому состоянию в обозримом будущем. Пока что точно известно лишь одно - у sysvinit была огромная фора по времени и это не слишком помогло, раз уж простота решения проблем *самими пользователями* все еще упоминается как одно из основных достоинств.
И еще, я говорил не о популярности проектов вообще, а о популярности *среди разработчиков*, и я не знаю почему Вы предпочли не заметить этот момент. Может не стоило так горячиться при виде слова "популярность"? Разработчики, как правило, гораздо лучше понимают реальные плюсы и минусы различных решений, чем все прочие, и они не руководствуются хвалебными или ругательными отзывами в "бложиках", они своими глазами видят все достоинства и недостатки, поскольку они напрямую с ними имеют дело. Суть в том, что проект без пользователей вполне может развиваться, а вот проект без разработчиков - вряд ли. И когда дистрибутив выбирает проект, на который он будет полагаться в ближайшем будущем, очевидно, что количество имеющихся и потенциальных будущих разработчиков этого проекта - достаточно важный фактор, ведь вряд ли кто-то захочет завязывать будущее своего дистрибутива на мертвый проект над которым никто не работает. Именно об этом я и говорил, а не о популярности среди пользователей и комментаторов на форумах - это в данном вопросе вообще практически не важно. Опять же, уточню на всякий случай, я не утверждаю, что sysvinit - мертвый проект, но прикинуть шансы на дальнейшее развитие всех альтернатив и учитывать это при выборе все-таки, наверное, стоит.
>> F20: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s...
> Никто и не отрицает существование багов, связанных с systemd.Так я для удобства и привёл скромную ссылочку :)
> Может Вы под впечатлением от каких-то других комментов так отреагировали?
Скорее справедливости ради (tm).
> Я не утверждаю, что systemd на данном этапе именно такой проект,
> тут вопрос в том, какой проект имеет больше шансов приблизиться
> к такому состоянию в обозримом будущем.Думаю, конкретно у systemd шансов было бы больше при... внедрении "по-хорошему", а не "добрым словом и пистолетом" (ck/pk, gnome3,
> Пока что точно известно лишь одно - у sysvinit была огромная
> фора по времени и это не слишком помогло,В смысле не помогло? Работает себе.
> раз уж простота решения проблем *самими пользователями* все еще упоминается
> как одно из основных достоинств.А это и есть одно из основных достоинств _инструмента_, предназначенного для решения широкого и малопредсказуемого заранее круга задач.
> И еще, я говорил не о популярности проектов вообще, а о популярности
> *среди разработчиков*, и я не знаю почему Вы предпочли не заметить
> этот момент. Может не стоило так горячиться при виде слова "популярность"?Вообще-то заметил и отвечал именно в этом ключе. Если что, AFAIK первые образы альта на systemd я и выпускал.
> Разработчики, как правило, гораздо лучше понимают реальные плюсы и минусы различных
> решений, чем все прочие, и они не руководствуются хвалебными или ругательными
> отзывами в "бложиках", они своими глазами видят все достоинства и недостатки,
> поскольку они напрямую с ними имеют дело.Несколько сложнее и вплоть до того, что стадные эффекты также имеют место быть (а то и руководство фирмы/проекта).
> Суть в том, что проект без пользователей вполне может развиваться
Не-а. Писать и не пользоваться самому -- верный путь к деградации проекта.
> [...] очевидно, что количество имеющихся и потенциальных
> будущих разработчиков этого проекта - достаточно важный факторЭто может показаться странным, но мне оно несущественно: куда важнее степень работоспособности проекта, характер развития и вменяемость апстрима. За других, разумеется, не говорю.
> но прикинуть шансы на дальнейшее развитие всех альтернатив и учитывать это
> при выборе все-таки, наверное, стоит.Разумеется.
> google://sytemd+debuggingСпасибо, дорогой. А теперь примените к залипанию без диагностики на выключении. Или к минутному примерно таймауту на складывании пользовательской сессии, которого и не просили.
> А теперь примените к залипанию без диагностики на выключении.http://freedesktop.org/wiki/Software/systemd/Debugging/#inde...
Не?> Или к минутному примерно таймауту на складывании пользовательской сессии, которого и не просили.
Видимо, надо писать багрепорт.
> Видимо, надо писать багрепорт.Именно так. И ждать... долго ждать. А если хочется ждать мало, то платить. Много платить. И, - вы удивитесь, платить РедХат и Поцтерингу. Собственно это и есть главная цель RH: увеличить маржу за тех. поддержку.
А теперь вопрос: а на черта мне ждать и платить, если я на OpenRC любой баг сам за 20 минут подлатаю, а? Ну, если нарвусь конечно... потому что за последние три года НИ РАЗУ не было ни одного! А все что мне пришлось там править сводилось к личной кастомизации системы.
>> Видимо, надо писать багрепорт.
> Именно так. И ждать... долго ждать. А если хочется ждать мало, то
> платить. Много платить. И, - вы удивитесь, платить РедХат и Поцтерингу.
> Собственно это и есть главная цель RH: увеличить маржу за тех.
> поддержку.А в OpenRC видать баги моментально исправляют?
> А теперь вопрос: а на черта мне ждать и платить, если я
> на OpenRC любой баг сам за 20 минут подлатаю, а? Ну,
> если нарвусь конечно... потому что за последние три года НИ РАЗУ
> не было ни одного! А все что мне пришлось там править
> сводилось к личной кастомизации системы.Валяйте: https://bugs.gentoo.org/buglist.cgi?component=OpenRC&product... Hosted Projects&resolution=--- 86*20/60 ~ 29 часов вам походу хватит.
>> А теперь примените к залипанию без диагностики на выключении.
> http://freedesktop.org/wiki/Software/systemd/Debugging/#inde...Спасибо, на эту страничку не натыкался. Плохо ещё и то, что параллелизм -- рассадник гонок, а вылавливать редко встречающееся или каждый раз готовить полигон для отлова -- извините, некогда.
>> Или к минутному примерно таймауту на складывании пользовательской сессии,
>> которого и не просили.
> Видимо, надо писать багрепорт.Багрепорт-то да, только вот там висяки в основном получаются, похоже. К тому же в 204 этой проблемы не было, соответствующая багофича была добавлена позже.
Т.е. есть проблемы, по которым есть смысл тратить время -- а есть такие, которые в проекте выбраны по постановке задачи. Залипания при полностью динамическом разрешении зависимостей в рантайме каждый раз -- именно из этой оперы.
PS re #61: необязательно; по мере наличия свободного времени.
>> google://sytemd+debugging
> Спасибо, дорогой. А теперь примените к залипанию без диагностики на выключении.journalctl -b -1 , не? И если оно один раз зависло, зависнет и второй раз, так?
> Или к минутному примерно таймауту на складывании пользовательской сессии, которого
> и не просили.Во-первых - ожидание завершения юнитов в systemd - 90 сек., а не минута. Во-вторых - поподробнее, пожалуйста (желательно с пруфом на багтрекер в апстриме)
> что для решения проблемы возмите кусок из моего софтахе-хе, а ведь не выйдет, даже если и очень захочется:
Tomasz Torcz: Hey, the code is written and it's free, upstart can execv() systemd-shutdown when going down.
Lennart Poettering: Nope, they cannot integrate it into Upstart, since the code might be free, but not covered under their CLA. They CLA is not just a great way to give people the finger who want to send patches to you, it's also a fantastic way to give the finger to yourself when you want to integrate existing code into your project. ;-)Я вообще не понимаю, как можно рассматривать хоть что-то от Canonical к интеграции в другие дистрибутивы, принимая во внимание их лицензионную политику.
> Я вообще не понимаю, как можно рассматривать хоть что-то от Canonical к
> интеграции в другие дистрибутивы, принимая во внимание их лицензионную политику.А дебианщики уже размахнулись поддерживать патчи для портабельности upstart out-of-tree, в виде патчей к дебиановскому пакету :)
Наверное, будет забавано, если учесть, что upstart тоже нехило привязан к линуксу, и придется переписать чуть ли половину кода.
А Поттеринг не планирует в ближайшее время убрать less из systemctl?
А зачем?
> А Поттеринг не планирует в ближайшее время убрать less из systemctl?alias systemctl='systemctl --no-pager'
Ага, давайте его ещё и из man уберём.
> Ага, давайте его ещё и из man уберём.не, из man не надо, да и убирается легко, достаточно перенаправить вывод не в терминал, типа: man xxx | cat
> не, из man не надо, да и убирается легко, достаточно перенаправить вывод
> не в терминал, типа: man xxx | catА systemctl xxx | cat писать низзя?
сугубо технические проблемы работы одной функции системы. не тянет оно на "главные новости"
забавно, у меня вот при использовании lvm, luks, raid и прочих nfs такой проблемы ни разу не возникало. Леннарт опять породил решение в поисках проблемы?
да, ты его разоблачил! спасибо тебе, отважный защитник!
из IRC по поводу этой темы:> LP is propagandizing systemd with showing such bugs in other init systems.
< so does systemd work with kernel 2.6.25 and reiserfs?
> I can ask people in that thread :)< well, short version: it can't, by design
< resilient software? not this decade!
>> LP is propagandizing systemd with showing such bugs in other init systems.
> < so does systemd work with kernel 2.6.25 and reiserfs?
>> I can ask people in that thread :)
> < well, short version: it can't, by design
> < resilient software? not this decade!Фанбои бесятся :)
> Фанбои бесятся :)Фанбои фанатеющие по чему?
> Фанбои фанатеющие по чему?Там есть своя политтусовка вокруг OpenRC.
> Там есть своя политтусовка вокруг OpenRC.И каких политических взглядов они придерживаются и интересы какой компании/государства/etc они представляют?
По нафиг никому не нужному RaiserFS же. -_-Цитата Леннарта на счёт одной из проблем с этою бедою:
Doesn't this problem kinda fix itself anyway due to the obsolescence of reiserfs?
http://lists.freedesktop.org/archives/systemd-devel/2011-Feb...Похороните вы его уже, а не тыкайте палочкой. Единственное место, где эта ФС была хороша это работа с большим количеством мелких файлов… и это везде решалось созданием кэша внутри одного большого, и работой уже с этим файлом. fsck же у этой ФС и вовсе гениально работает, инициируя без предупреждения перестройку дерева файлов. Из-за этого если на разделе с raiserfs хранить бэкап другого такого раздела без сжатия или шифрации, то при перестройке дерева вместо файла бэкапа можно получить странное нечто, состоящее из содержимого диска и бэкапа вместе.
> Похороните вы его уже, а не тыкайте палочкой.спасибо. твоего очень ценного мнения очень не хватало. как же без твоих-то ценных указаний? «хоронильщик», йопт…
Всегда пожалуйста, был очень рад помочь, обращайтесь.
> Из-за этого если на разделе с raiserfs хранить бэкап другого такого раздела без сжатия или шифрации, то при перестройке дерева вместо файла бэкапа можно получить странное нечто, состоящее из содержимого диска и бэкапа вместе.Ага! Попался! Давно хотел спросить (не ради смеху, а, правда, интересно) у кого-нибудь, хаящего рейзер по этой причине. Как данная проблема решается в других фс (хотя бы в одной из ext{2,3,4}, xfs)? Как вообще утилита, получающая кусок байтовой последовательности, может понять, что является основной файловой системой, а что - файловой системой образа, лежащего на основной системе?
>> Фанбои бесятся :)
> Фанбои фанатеющие по чему?по системды. прямо тут, на опеннете. как только их в очередной раз тычут носом в то, что системды — кусок говна, они начинают кричать про «haters gonna hate», «системды-ненавистников» и прочую ерунду.
Забыл что они ещё рассказывают про не читаемые портянки скриптов, бричку и космолёт ну и сами не пользуются системд.
К сожалению, при всех описанных плюсах systemd, он все еще не предназначен для использования в в большинстве ситуаций, отходящих от стандартных use-case. До сих пор нет возможности оставить от systemd только систему инициализации, убрав все эти journald и другие навязанные сервисы.
Напоминает галочки в виндовых инсталляторах - "установить яндекс.бар, бесплатный антивирус, шахматы и поэтесс+", активированные по умолчанию.
> К сожалению, при всех описанных плюсах systemd, он все еще не предназначен
> для использования в в большинстве ситуаций, отходящих от стандартных use-case.Наоборот :)
systemd изначально разработан модульным и расширяемым, в отличие от скриптов, у разработчиков которых всегда есть отмазка "если пользователю надо, он перепишет". В результате мы имеем то, что имеем - при отклонении от стандартных use case приходится лезть в дебри скриптов, вместо того, чтобы добавить один-два простых юнита, как в systemd.> До сих пор нет возможности оставить от systemd только систему инициализации, убрав
> все эти journald и другие навязанные сервисы.Нельзя отключить только journald и udev. Потому что кто-то должен обрабатывать обращения программ к системному логу (хотя бы в режиме заглушки) и события устройств.
Все остальное можно отключить.> Напоминает галочки в виндовых инсталляторах - "установить яндекс.бар, бесплатный антивирус, шахматы и поэтесс+", активированные по умолчанию.
Почему, как только что-то работает без траха - так сразу "винда"?
>Почему, как только что-то работает без траха - так сразу "винда"?Э-э-э, потому что это откровенная брехня?
> Наоборот :)
> systemd изначально разработан модульным и расширяемым, в отличие от скриптов, у разработчиков
> которых всегда есть отмазка "если пользователю надо, он перепишет". В результате
> мы имеем то, что имеем - при отклонении от стандартных use
> case приходится лезть в дебри скриптов, вместо того, чтобы добавить один-два
> простых юнита, как в systemd.Понятие "простоты" юнита субъективно. Большинство пользователей не полезет ни в sysvinit, ни в systemd. При этом, shell я уже много лет знаю - это стандарт между всеми solaris/bsd/linux, как минимум, а systemd-unit - это linux-specific заморочка, появившаяся чуть ли не вчера. Как Вы думаете, что мне будет субъективно "проще"? Как и многим другим людям, которые пришли в эту область не 1-2 года назад.
Не надо, пожалуйста, вспоминать про саморазвитие, необходимое для профессионалов и т.д.
Саморазвитие - это дополнительно к системному администрированию освоить функциональное программирование на erlang/haskell, к примеру, а никак не очередное перебаламучиване системы инициализации.> Нельзя отключить только journald и udev. Потому что кто-то должен обрабатывать обращения
> программ к системному логу (хотя бы в режиме заглушки) и события
> устройств.Мне не нужны эти демоны в моей системе. Ни один, ни другой. К примеру, я использую devtmpfs+mknode, и логирование через syslog-ng сразу в сетевой сокет, а "фирменное барахло от поттеринга" в моей системе будет только бесполезно жрать память.
Впрочем, udev который вроде был вполне готов к спокойной эксплуатации на долгие предстоящие годы, они тоже поломали.> Все остальное можно отключить.
Если бы все остальные достаточно спорные решения, вроде http-сервера в системе инициализации еще и отключить было бы нельзя, думаю, даже самые ярые сторонники нового велосипеда призадумались бы.
Правильно писал pavlinux в соседней теме - это не развитие, это стагнация. Те вещи, которые уже работали, давно, хорошо работали, заменяются новыми и неработающими.
А то, чего не было - так и нет до сих пор, уже десяток лет.
>При этом, shell я уже много лет знаю - это стандарт между всеми solaris/bsd/linux, как минимум, а systemd-unit - это linux-specific заморочка, появившаяся чуть ли не вчера.Да дело даже не в этом. Для скриптов вполне можно использовать что-то типа этого — http://bashdb.sourceforge.net/ Для текстового файла (systemd-unit) такой возможности нет в принципе.
Даже в xml можно провести формальную валидацию, в txt — нет.
К тому же стиль systemd разделяет отладку на 2-а — текстовой файл и собственно сам демон (man sd_* — вместо звёздочки два раза «таб», если есть башкомплешн), а ковырятся с отладкой сторонних 100500 демонов — то ещё удовольствие. Например:
>NAME
> sd_listen_fds, SD_LISTEN_FDS_START - Check for file descriptors passed by the system manager
>DESCRIPTION
> sd_listen_fds() shall be called by a daemon to check for file descriptors passed by the init system as part of the socket-based activation logic.
>…
>RETURN VALUE
> On failure, this call returns a negative errno-style error code. If $LISTEN_FDS/$LISTEN_PID was not set or was not correctly set for this daemon and hence no file descriptors were received, 0 is returned. Otherwise, the number of file descriptors passed is returned. The application may find them starting with file descriptor SD_LISTEN_FDS_START, i.e. file descriptor 3.И выяснение кто из этих 2-х виноват уже не такая тривиальная задача, как со скриптами.
системды-специфичное апи вообще нафиг не нужно.
>Напоминает галочки в виндовых инсталляторах - "установить яндекс.бар, бесплатный антивирус, шахматы и поэтесс+", активированные по умолчанию.Угу, только там галки можно снять и ненyжно не ставить.
Да, улучшающееся качество статей на опеннете не может не радовать. Аноним молодец!
> Примечание: Интересно, что проблема перемонтирования корневой файловой системы, похоже, присутствует не только в Upstart, но и в OpenRC — там она выражается в зависании процесса выключения с сообщением «failed because we are using /», например, после запуска prelink. Несмотря на то, что разработчики OpenRC отмечают такие ошибки, как UNCONFIRMED, опытные пользователи Gentoo знают о проблеме, и рекомендуют добавлять команду «telinit u» в скрипт выключения ОС — /etc/init.d/mount-ro.вся суть велосипедостроения -- в одном обзаце :)
опытные пользователи оказались умнее разработчиков :-)
[хотя -- отдаёт желтезной]
>[хотя -- отдаёт желтезной]И ещё какой. Согласитесь, что это
>sys-apps/openrc-0.10.5 fails to remounts reiserfs root file system read only on reboot: failed because we are using /и это
>приводящей к повреждению корневой файловой системы в процессе выключения компьютера.Несколько разные вещи.
Мягко говоря. :DЗыж
Более жёлто было бы написать — «Использование всего, что не есть/является systemd убивает».
Постеснялись? :D
Я специально для Вас выпишу основные пункты новости:
Upstart повреждает ФС в редких случаях из-за проблем с перемонтированием корневой файловой системы, что решается перезапуском upstart.
OpenRC страдает от той же проблемы с перемонтированием, что опять же решается перезапуском OpenRC.
Не благодарите.
Забавно, мне не нужно было читать новость, чтобы убедится, что когда повис намертво systemd с ошибкой can't unmount /tmp, после чего root требовал fsck.
И это был не редкий случай, несколько раз через fsck пришлось исправлять вручную (мне повезло, исправлялось до рабочего состояния — lost+found не считаю).И?
Или вот баг без ответа вообще с 2013-04-05 https://bugs.freedesktop.org/show_bug.cgi?id=63134
Хорошо, допустим им наплевать, на все дистры, кроме рэдхэтовских, ну и?
https://bugzilla.redhat.com/show_bug.cgi?id=1026119
> Fedora 20 fails to unmount /home, /tmp and all /dev/mapper/luks- partitions on every shutdownтоже самое.
Комментарии потеринга (хотя бы в этих багах) приветствуются. Вместо этого он решил поучаствовать в багтрэккерах апстарта и опенрк?
Как это мило! :D
> Комментарии потеринга (хотя бы в этих багах) приветствуются. Вместо этого он решил
> поучаствовать в багтрэккерах апстарта и опенрк?
> Как это мило! :Dочевидно, перед тем как комментировать -- он решил посмотреть как это сделано у других :)
Самое забавное, что на свои баги у него нет времени, но написать столь развёрнутое эссе по поводу upstart оно нашлось.
Пока весь opennet читает, у него есть время подумать ))))))))
Сунь-цзы нервно курит за углом ;)
эх жаль лёня отлично поработал и доходчиво рассказал о сложной проблеме, но никто не будет читать...
"Если в то время, когда файл оставался открытым на чтение для некоторого процесса, этот файл был перезаписан целиком (удален и создан заново), процесс продолжает работать со старой версией файла"*FACEPALM*
Мне одному кажется, что маразм породил маразм? Если файл открыт на чтение и кто-то пытается файл прибить, есть два _разумных_ варианта:
1. Файл прибиваем, читателю возвращаем ошибку.
2. Убивателю возвращаем ошибку, файл остаётся жить.При этом это не взаимоисключающие пункты, т.к. в системе можно поддерживать оба. Например, для tail подойдёт вариант 1, а для /dev/timer - 2.
> *FACEPALM*
> Мне одному кажется, что маразм породил маразм? Если файл открыт на чтение
> и кто-то пытается файл прибить, есть два _разумных_ варианта:Это не разумные варианты, это _твои _виндовые привычки.
Велкам то зе нью брэйв йуникс уорлд, муа пети!
> Примечание: Интересно, что проблема перемонтирования корневой файловой системы, похоже,
> присутствует не только в Upstart, но и в OpenRCА почему неинтересно то, что она отсутствует в sysvinit?
Любим геройский решать проблемы, которые сами и создали?
я просто оставлю здесь этоGentoo + openrc:
# lsof -w | grep init
init 1 root cwd DIR 8,2 664 2 /
init 1 root rtd DIR 8,2 664 2 /
init 1 root txt REG 8,2 35156 43461915 /sbin/init
init 1 root mem REG 8,2 1738080 44692768 /lib/libc-2.17.so
init 1 root mem REG 8,2 134132 44692769 /lib/ld-2.17.so
init 1 root 10u FIFO 0,5 0t0 703 /dev/initctl
#
> я просто оставлю здесь этожуть какая выше нарисована.
init 1 root cwd DIR 8,1 61440 2 /
init 1 root rtd DIR 8,1 61440 2 /
init 1 root txt REG 8,1 559832 9717 /sbin/init
init 1 root 10u FIFO 0,12 0t0 4252 /dev/initctl
вот так надо. слака, bsd-style init с поддержкой sysv совместимости из коробки.