форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
Сообщение от opennews (??) on 28-Янв-14, 10:26
Леннарт Поттеринг, возглавляющий разработку системного менеджера 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... Новость: http://www.opennet.dev/opennews/art.shtml?num=38943
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Анализ реализаций алгоритма остановки ОС в различных система..."	–7 +/–
Сообщение от Аноним (??) on 28-Янв-14, 10:26
>Леннарт Поттеринг, возглавляющий разработку системного менеджера systemd, прокомментировал ситуацию, сложившуюся вокруг ошибки в Upstart Минутка рекламы, не переключайтесь.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	47. "Анализ реализаций алгоритма остановки ОС в различных система..."	–6 +/–
	Сообщение от анон on 28-Янв-14, 13:41
	перестал читать после первых 2х слов
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	50. "Анализ реализаций алгоритма остановки ОС в различных система..."	+6 +/–
	Сообщение от pavlinux (ok) on 28-Янв-14, 13:55
	Ведение войны заключается в том, чтобы предоставлять противнику действовать согласно его намерениям и ТЩАТЕЛЬНО ИЗУЧАТЬ их; затем сосредоточить все его внимание на чем-нибудь одном и убить его полководца, хотя бы он и был за тысячу миль. Это и значит уметь искусно сделать дело.                                                               Сунь-цзы. © Made in China.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	114. "Анализ реализаций алгоритма остановки ОС в различных система..."	+4 +/–
	Сообщение от ананим on 28-Янв-14, 18:07
	Дожили. http://ru.wikipedia.org/wiki/%D0%A1%D1%8... зыж «Истинное правило военного искусства, — учил Суворов, — прямо напасть на противника с самой чувствительной для него стороны, а не сходиться, робко пробираясь окольными дорогами… дело может быть решено только прямым смелым наступлением». «Русские прусских всегда бивали, что ж тут перенять?», «Пудра не порох, букля не пушка, коса не тесак, и я не немец, а природный русак». «не проиграл ни одного сражения, причем все они были выиграны при численном превосходстве неприятеля» (более 60 сражений) ззыж «приятно быть русским в такое славное для России время». (Петрушевский А. «Генералиссимус князь Суворов» 1884 г. С-Петербург, т.3, с.182-184).
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	118. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Andrey Mitrofanov on 28-Янв-14, 18:33
	> князь Суворов» 1884 г. С-Петербург, т.3, с.182-184). W://Искусство_войны ""долгое время датировался концом VI — началом V века до н. э. Кто победил, кит или слон?
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	122. "Анализ реализаций алгоритма остановки ОС в различных система..."	–2 +/–
	Сообщение от ананим on 28-Янв-14, 18:52
	Боюсь в тайге Сибири они оба долго не протянут. Это к вопросу «у(естност)и».
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	123. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от ананим on 28-Янв-14, 18:54
	/«у(естност)и»/«у(местност)и»
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	140. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 19:37
	А ядерная ракета испаряет на...й все и вся совершенно независимо от made in :).
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	149. "Анализ реализаций алгоритма остановки ОС в различных система..."	+7 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 20:08
	От made in зато зависит, долетит она до "всего", или нет.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	153. "Анализ реализаций алгоритма остановки ОС в различных система..."	+2 +/–
	Сообщение от ананим on 28-Янв-14, 20:17
	Это фатальное заблуждение предполагать, что ядерная ракета не зависит made in :D
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	185. "Анализ реализаций алгоритма остановки ОС в различных система..."	+4 +/–
	Сообщение от angra (ok) on 29-Янв-14, 00:19
	Большинство уверено, что ядерный заряд жахнет в полную мощь, если его просто подвергнуть обычному взрыву. Они вообще не в курсе, в чем состоит основная проблема создания ядрённых бомб.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	184. "Анализ реализаций алгоритма остановки ОС в различных система..."	+3 +/–
	Сообщение от angra (ok) on 29-Янв-14, 00:17
	Тут все как обычно. Практика единственное мерило теории. Практика китайских полководцев подсказала, что их теорией можно просто подтереться. Какой-то необразованный монгол по имени Темучин их раскатал в блин уступая во всем. И он был далеко не единственный, кто на протяжении тысячелетий жестко дрючил китайских титеретиков.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	196. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от Онаним on 29-Янв-14, 10:10
	Если бы Вы разбирались в истории Поднебесной, то Вы с удивлением заметили бы, что передернули.
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	209. "Анализ реализаций алгоритма остановки ОС в различных система..."	–2 +/–
	Сообщение от mverepin (ok) on 29-Янв-14, 17:26
	> Если бы Вы разбирались в истории Поднебесной, то Вы с удивлением заметили > бы, что передернули. Толераст? Уважай всех кромя своих сородичяй?
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	197. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от Sabakwaka (ok) on 29-Янв-14, 10:12
	Совсем больной...
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	212. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от pavlinux (ok) on 29-Янв-14, 23:48
	> ... Какой-то необразованный монгол по имени Темучин их раскатал в блин уступая во всем. > И он был далеко не единственный, кто на протяжении тысячелетий жестко дрючил китайских > титеретиков. И в какой жопе сейчас Монголия? :)
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	66. "Анализ реализаций алгоритма остановки ОС в различных система..."	+2 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:35
	> перестал читать после первых 2х слов Правильно. А то ведь прочитаешь - потом осуждать нельзя будет.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	168. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Vasya (??) on 28-Янв-14, 21:13
	Зря. Перевод просто шикарен. Много полезной информации. Лёня, как всегда, не упустил шанс потроллить =)
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	169. "Анализ реализаций алгоритма остановки ОС в различных..."	+2 +/–
	Сообщение от arisu (ok) on 28-Янв-14, 21:23
	> Зря. Перевод просто шикарен. Много полезной информации. Лёня, как всегда, не упустил > шанс потроллить =) ты знаешь, если «тролль» не отличим от идиота, то совершенно не важно, идиот ли он «где-то там в своей глубине».
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	172. "Анализ реализаций алгоритма остановки ОС в различных..."	+/–
	Сообщение от Andrey Mitrofanov on 28-Янв-14, 21:39
	> «тролль» не отличим от идиота, то совершенно не важно, > идиот ли он «где-то там в своей глубине». Ты эта, чьих будешь? С такими сравнениями на наше болото не заходи.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	173. "Анализ реализаций алгоритма остановки ОС в различных..."	+1 +/–
	Сообщение от arisu (ok) on 28-Янв-14, 21:40
	а я не тролль, я честный дурак. просто на фоне «интеллектуального большинства» выгляжу умным.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	178. "Анализ реализаций алгоритма остановки ОС в различных..."	+/–
	Сообщение от Andrey Mitrofanov on 28-Янв-14, 21:50
	>просто на фоне «интеллектуального большинства» Так, пацаны! Клиент с первого раза не понял. Всем запомнить эту косоглазую харю в передничке, пойдёт нашим перелеском, всем запомнить, за ним должок. >/<
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	179. "Анализ реализаций алгоритма остановки ОС в различных..."	+2 +/–
	Сообщение от arisu (ok) on 28-Янв-14, 21:58
	так я ж без маскировки не пойду. фиг вы меня узнаете в чепчике и с усами… упс.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	171. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Andrey Mitrofanov on 28-Янв-14, 21:37
	> Зря. Перевод просто шикарен. Много полезной информации. Лёня, как всегда, не упустил > шанс потроллить =) Пусть на наше болото заскочит, там поглядим, каков он "троль". Фабрикует весьма незатейливо, хотя бейт из него [самого] знатный. На наживку сойдёт.
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

2. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
Сообщение от 3draven (ok) on 28-Янв-14, 10:27
Пеар systemd в надежде попасть в дебиан?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Анализ реализаций алгоритма остановки ОС в различных система..."	+8 +/–
	Сообщение от anonymouse on 28-Янв-14, 10:51
	Как же сможет systemd прожить без deb?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	36. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от svsd_val (ok) on 28-Янв-14, 12:41
	Угу Debian'у он особо то и не нужен, особенно если учитывать что Systemd - наглухо прибит напрочь заржавевшими гвоздями к ядру Linux. Что же прикажите делать тогда с остальными ядрами Debian (Hurd,kFreeBSD,kNetBSD) ??
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	37. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от vi on 28-Янв-14, 13:15
	> Угу 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
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	39. "Анализ реализаций алгоритма остановки ОС в различных система..."	–3 +/–
	Сообщение от svsd_val (ok) on 28-Янв-14, 13:18
	Угу, но зачем им держать две системы инициализации в этом случае, если можно довести напильником Upstart? благо он более документирован и менее привязан к ядру Linux.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	41. "Анализ реализаций алгоритма остановки ОС в различных система..."	+2 +/–
	Сообщение от vi on 28-Янв-14, 13:29
	> Угу, но зачем им держать две системы инициализации в этом случае, если > можно довести напильником Upstart? благо он более документирован и менее привязан > к ядру Linux. Без грубостей ;) : Может еще, Debian-щикам сбросится на очередную путевку в космос для Космонавта? Пускай уже этот господин сделает что то полезное и для Debian (или я много кое чего не знаю в этом вопросе (наверняка))! А то вон последнее время пыль вокруг CLA поднимается, и прочее :( И да, бронепоезд должен стоять на запасном пути. Правда его от ржавчины иногда приходится чистить (но это необходимое злощастье в придачу ;)
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	132. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от svsd_val (ok) on 28-Янв-14, 19:21
	Ага так говорят озабоченные арчеводы и им подобные, которые дальше x86/x64 не идут, так как для них мир на этом и заканчивается. )))) В отличии от большинства дистрибутивов Debian работает на множестве платформ и множестве ядер, и он выбирает конкретные плюсы и минусы исходя из всех платформ и всех ядер. Так или иначе SysVinit скорее всего будет заменён, иначе об этом не говорили бы ... и не ставился вопрос на собрании что выбрать Debian systemd или upstart
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	48. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от asavah (ok) on 28-Янв-14, 13:43
	А зачем гента их держит? Для мантэйнеров - больше гимора, для одминов больше гибкости. Простите но в данном случае я за гимор для мантэйнеров и за большее количество опций для себя.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	100. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от rshadow (ok) on 28-Янв-14, 16:08
	> Для мантэйнеров - больше гимора А вы майнтейнер? А геммора больше, это потратить пару часов на написание юнита/скрипта/конфига? иди даже на просмотр и мерж патча... Я не за systemd, но каждый первый тут мнит что знает проблемы майнтейнеров...
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	62. "Анализ реализаций алгоритма остановки ОС в различных система..."	–2 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:31
	> Угу, но зачем им держать две системы инициализации в этом случае, если > можно довести напильником 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 дело дойдет.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	91. "Анализ реализаций алгоритма остановки ОС в различных система..."	+2 +/–
	Сообщение от Crazy Alex (ok) on 28-Янв-14, 15:20
	В апстарте по самой его природе фичи жестко не прибиваются. Поэтому там cgroups и прочее - не проблема.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	92. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от chinarulezzz (ok) on 28-Янв-14, 15:24
	>> благо он более документирован > Неа. http://www.freedesktop.org/software/systemd/man/ This index contains 308 entries, > referring to 149 individual manual pages. при этом, поттеринг говорит: мы в документацию не успеваем, смотри в код, он первостепенней :D > Upstart нервно курит в сторонке :) действительно. >> и менее привязан к ядру Linux. > Это легко поправить. Сейчас разработчики Upstart уже работают над поддержкой cgroups, а опционально. > скоро и до kdbus дело дойдет. опционально.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	111. "Анализ реализаций алгоритма остановки ОС в различных система..."	+4 +/–
	Сообщение от ананим on 28-Янв-14, 17:56
	>ри этом, поттеринг говорит: мы в документацию не успеваем, смотри в код, он первостепенней :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
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	116. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от chinarulezzz (ok) on 28-Янв-14, 18:22
	так вот откуда поттеринг знания почерпнул чтоб прокомментировать апстарт.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	119. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 18:35
	> так вот откуда поттеринг знания почерпнул чтоб прокомментировать апстарт. Скорее всего отсюда :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, и отписывается в треде далеко не два человека.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	124. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от chinarulezzz (ok) on 28-Янв-14, 18:54
	>> так вот откуда поттеринг знания почерпнул чтоб прокомментировать апстарт. > Скорее всего отсюда :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
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	128. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 19:06
	>>> так вот откуда поттеринг знания почерпнул чтоб прокомментировать апстарт. >> Скорее всего отсюда :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.../
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	147. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от chinarulezzz (ok) on 28-Янв-14, 19:59
	> Ага. Лучше бы православный Патреговский юзали: > http://www.linuxquestions.org/questions/slackware-14/cryptse.../ У самого есть криптораздел и слакварь на борту. Никогда не встречал подобное. Судя по обильному количеству комментариев - не я один. > http://www.linuxquestions.org/questions/slackware-14/large-p.../ вообще не то.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	129. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от ананим on 28-Янв-14, 19:09
	Или отсюда — 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 вообще ни ответа, ни привета.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	135. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 19:31
	> Или отсюда — https://bugs.gentoo.org/show_bug.cgi?id=493874 >>sys-apps/systemd-208-r2 hangs activating encrypted swap partition I 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 вообще ни ответа, > ни привета.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	138. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от ананим on 28-Янв-14, 19:36
	>Вы статус CVE-шек хоть смотрели? Т.е. теперь можно сказать что их и не было?
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	142. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 19:39
	>>Вы статус CVE-шек хоть смотрели? > Т.е. теперь можно сказать что их и не было? Т.е. кидаться закрытыми багами как-бе нормально?
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	143. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от ананим on 28-Янв-14, 19:42
	Ну бревно, вытащенное похтерингом из апстарта, ты же не заметил? Вдруг и про уязвимости не в курсе.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	145. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от ананим on 28-Янв-14, 19:53
	External Source: CONFIRM Name: https://bugzilla.redhat.com/show_bug.cgi?id=859060 Hyperlink:https://bugzilla.redhat.com/show_bug.cgi?id=859060 https://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]
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	121. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от ананим on 28-Янв-14, 18:40
	Меня этот баг настолько заипал в своё время, что я вернулся с systemd обратно на openrc. зыж http://ru.wikipedia.org/wiki/%D0%A1%D1%8... >«Истинное правило военного искусства, — учил Суворов, — прямо напасть на противника с самой чувствительной для него стороны, а не сходиться, робко пробираясь окольными дорогами… дело может быть решено только прямым смелым наступлением». Всё потому, чтобы «противник» не напал первым на тебя «с самой чувствительной для тебя стороны (https://bugs.freedesktop.org/buglist.cgi?quicksearch=systemd...)». :D
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	120. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 18:37
	>>ри этом, поттеринг говорит: мы в документацию не успеваем, смотри в код, он первостепенней :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)
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	125. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от ананим on 28-Янв-14, 18:57
	>А в своем глазу значит... хм, похтеринг сабж начал, ему дерьмо и убирать.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	127. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 19:02
	>>А в своем глазу значит... > хм, похтеринг сабж начал, ему дерьмо и убирать. А-а-а! Он походу успел и в OpenRC нагадить! А мужики-то не знают )
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	126. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 18:59
	>>ри этом, поттеринг говорит: мы в документацию не успеваем, смотри в код, он первостепенней :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. Мужики, это бы надо поправить, только вот хз как ) Прошло три года...
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	56. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:23
	> Systemd - наглухо прибит напрочь заржавевшими гвоздями к ядру Linux. Ну не то что бы к ядру Linux, он скорее прибит гвоздями к RedHat.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	59. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:28
	> Ну не то что бы к ядру Linux, он скорее прибит гвоздями к RedHat. А также к арчу, опенсусе... в общем, половине линуксов.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	65. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от chinarulezzz (ok) on 28-Янв-14, 14:35
	к апстрим проектам, контролирующих редхат. Здесь имеется в виду компания, а не дистрибутив.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	69. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:39
	> к апстрим проектам, контролирующих редхат. Здесь имеется в виду компания, а не дистрибутив. Редхат контролируется опенсорсниками? Ну, это уже давно не тайна :)
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	80. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от chinarulezzz (ok) on 28-Янв-14, 14:55
	>> к апстрим проектам, контролирующих редхат. Здесь имеется в виду компания, а не дистрибутив. > Редхат контролируется опенсорсниками? Ну, это уже давно не тайна :) контролирует :) возможно не так выразился.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	84. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:58
	> контролирует :) возможно не так выразился. Да нет, как раз правильно.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	77. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:53
	> к апстрим проектам, контролирующих редхат. Здесь имеется в виду компания, а не дистрибутив. "Лучше убью свои данные, чем поставлю проги от клятого редхата!"?
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	82. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от chinarulezzz (ok) on 28-Янв-14, 14:56
	>> к апстрим проектам, контролирующих редхат. Здесь имеется в виду компания, а не дистрибутив. > "Лучше убью свои данные, чем поставлю проги от клятого редхата!"? у меня убунта с версии 7.04. Не знаю когда там появился апстарт - но данные никогда не убивал. Не везёт.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	85. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:59
	> у меня убунта с версии 7.04. Не знаю когда там появился апстарт > - но данные никогда не убивал. Не везёт. "Я еще никогда не умирал. Значит, я бессмертен, да?"
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	88. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от chinarulezzz (ok) on 28-Янв-14, 15:11
	>> у меня убунта с версии 7.04. Не знаю когда там появился апстарт >> - но данные никогда не убивал. Не везёт. > "Я еще никогда не умирал. Значит, я бессмертен, да?" Джо есть, просто он неуловим.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	105. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от jOKer (ok) on 28-Янв-14, 17:16
	>>Ну не то что бы к ядру Linux, он скорее прибит гвоздями к RedHat. >А также к арчу, опенсусе... в общем, половине линуксов. Скорее арч и опенсусе прибиты с помощью systemd к RedHat /fixed
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	63. "Анализ реализаций алгоритма остановки ОС в различных система..."	–2 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:33
	> Угу Debian'у он особо то и не нужен, особенно если учитывать что > Systemd - наглухо прибит напрочь заржавевшими гвоздями к ядру Linux. Заржавевшие гвозди, а также ржавые цепи, погребальные саваны и загробный хохот прочно ассоциируются как раз не с Linux, а с некоторыми конкурирующими ядрами :) > Что же прикажите делать тогда с остальными ядрами Debian (Hurd,kFreeBSD,kNetBSD) ?? Эти проекты начаты в основном от того, что людям хочется поизвращаться. Так пусть извращаются, кто ж им мешает?
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	186. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от Led (ok) on 29-Янв-14, 00:21
	> Эти проекты начаты в основном от того, что людям хочется поизвращаться. Как точно сказано про systemd.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	141. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 19:38
	> же прикажите делать тогда с остальными ядрами Debian (Hurd,kFreeBSD,kNetBSD) ?? Оставить им инит, "на отъ...сь". Некроманам и инициализация некроманская.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	64. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:35
	> Пеар systemd в надежде попасть в дебиан? Вряд ли. Учитывая, что от обсуждения дебианщиков от откосил, сказав "у меня много работы, извините". Вместо того, чтобы убивать по полдня на опровержение FUD от Лангасека.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	76. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Andrey Mitrofanov on 28-Янв-14, 14:52
	> Пеар systemd в надежде попасть в дебиан? Коварный план! "Срочно в номер! Red Hate передаёт systemd и Леонарда П. в проект Debian."
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	79. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Andrey Mitrofanov on 28-Янв-14, 14:53
	s/в проект/под крылошко/
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

3. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
Сообщение от anonymous (??) on 28-Янв-14, 10:33
> файловая система будет ждать завершения этого процесса Вот интересно, каким образом в файловой системе реализовано ожидание завершения процесса?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от asd (??) on 28-Янв-14, 10:49
	По файловым дескрипторам - если не освобождены, значит работает
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	38. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от anonymous (??) on 28-Янв-14, 13:16
	>По файловым дескрипторам - если не освобождены, значит работает Я про само ожидание, а не его условие.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	53. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от pavlinux (ok) on 28-Янв-14, 13:59
	>>По файловым дескрипторам - если не освобождены, значит работает > Я про само ожидание, а не его условие. Очевидно драйвером FS, проверяющим условия.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	112. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от anonymous (??) on 28-Янв-14, 18:00
	>Очевидно драйвером FS, проверяющим условия. Из текста новости это не очевидно.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	188. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от ig0r (??) on 29-Янв-14, 03:08
	очевидно что процессом монтирования/размонтирования занимается драйвер файловой системы.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	193. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от anonymous (??) on 29-Янв-14, 09:04
	>очевидно что процессом монтирования/размонтирования занимается драйвер файловой системы. А завершение процесса кто ждёт?
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	151. "Анализ реализаций алгоритма остановки ОС в различных..."	+1 +/–
	Сообщение от arisu (ok) on 28-Янв-14, 20:16
	>> файловая система будет ждать завершения этого процесса > Вот интересно, каким образом в файловой системе реализовано ожидание завершения процесса? путём приятия героина внутрь теми, кто такое пишет. файловой системе глубоко наплевать на процессы, её интересуют только мыши^w открытые fd. как последний fd закрылся — всё, свобода.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	174. "Анализ реализаций алгоритма остановки ОС в различных..."	+/–
	Сообщение от Andrey Mitrofanov on 28-Янв-14, 21:43
	>>> файловая система будет ждать завершения этого процесса Внимательно!^^ >> Вот интересно, каким образом в файловой системе реализовано ожидание завершения процесса? > закрылся — всё, свобода. Он про то, что в _самой _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)) # _
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

4. "Анализ реализаций алгоритма остановки ОС в различных система..."	+11 +/–
Сообщение от славян on 28-Янв-14, 10:39
не думаю что это пиар. скорее заявление, которое должно показать его квалификацию. и да возможно есть желание получить бонусы от использования системд в дебиан. разработчиков то в дебиан тоже хватает.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	67. "Анализ реализаций алгоритма остановки ОС в различных система..."	–5 +/–
	Сообщение от chinarulezzz (ok) on 28-Янв-14, 14:36
	> не думаю что это пиар. скорее заявление, которое должно показать его квалификацию. ты прав что ты неправ.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	70. "Анализ реализаций алгоритма остановки ОС в различных система..."	–3 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:41
	>> не думаю что это пиар. скорее заявление, которое должно показать его квалификацию. > ты прав что ты неправ. Ну, вообще-то Ленька наглядно показал, что манагеры, пишущие upstart, не разбираются в матчасти, и поэтому их костыли не всегда работают. И, технически, он абсолютно прав.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	90. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от chinarulezzz (ok) on 28-Янв-14, 15:17
	>>> не думаю что это пиар. скорее заявление, которое должно показать его квалификацию. >> ты прав что ты неправ. > Ну, вообще-то Ленька наглядно показал, что манагеры, пишущие upstart, не разбираются в > матчасти, и поэтому их костыли не всегда работают. И, технически, он > абсолютно прав. костыли от лёньки судя по всему, systemd-shutdownd - это просто еще один бинарь для того чтоб решить проблему, решаемую через «telinit u»? Ну, простое, изящное и элегантное решение. P.S. Все костылят, здесь ни systemd ни upstart не исключение. Действия лёни полезны для внимания апстартовцев. Пусть обе команды, конкурируя друг с другом, делают свои продукты лучше.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	195. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Аноним (??) on 29-Янв-14, 10:02
	> костыли от лёньки судя по всему, systemd-shutdownd - это просто еще один бинарь для того чтоб решить проблему, решаемую через «telinit u»? Ну, простое, изящное и элегантное решение. То есть перезапуск инита для завершения работы - это не костыль? А простенький процесс, делающий ровно то, что нужно - это костыль? Ваша логика мне напоминает логику МС - это они любят что-нибудь перезапустить, систему перезагрузить и т.д. Таким как вы дай волю, так вы и реактор на АЭС перезапустите, когда нужно лампочку в сортире поменять, и еще будете потом утверждать, что это "простое, изящное и элегантное решение".
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	198. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от vi on 29-Янв-14, 12:36
	>> костыли от лёньки судя по всему, systemd-shutdownd - это просто еще один бинарь для того чтоб решить проблему, решаемую через «telinit u»? Ну, простое, изящное и элегантное решение. > То есть перезапуск инита для завершения работы - это не костыль? А > простенький процесс, делающий ровно то, что нужно - это костыль? > Ваша логика мне напоминает логику МС - это они любят что-нибудь перезапустить, > систему перезагрузить и т.д. > Таким как вы дай волю, так вы и реактор на АЭС перезапустите, > когда нужно лампочку в сортире поменять, и еще будете потом утверждать, > что это "простое, изящное и элегантное решение". А чем по Вашему init должен заниматься? И почему его так страшно перезапускать?
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	199. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 29-Янв-14, 13:00
	> А чем по Вашему init должен заниматься? И почему его так страшно > перезапускать? Почитаешь Поттера, так его просто запускать страшно -- со всеми этими перменными и отваливающимися _внешними разделами, устройствами, дин.библиотеками, локализациями и прочими независимыми зависимостями. Оно же может не взлететь в любую же секунду!! </ужосшокк>
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	200. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от vi on 29-Янв-14, 13:04
	>> А чем по Вашему init должен заниматься? И почему его так страшно >> перезапускать? > Почитаешь Поттера, так его просто запускать страшно -- со всеми этими перменными > и отваливающимися _внешними разделами, устройствами, дин.библиотеками, локализациями > и прочими независимыми зависимостями. Оно же может не взлететь в любую > же секунду!! </ужосшокк> Да ладно, "миллион" лет уже работает и еще столько же проработает (сарказм понят ;)
	Ответить | Правка | ^ к родителю #199 | Наверх | Cообщить модератору

	106. "Анализ реализаций алгоритма остановки ОС в различных система..."	+2 +/–
	Сообщение от Stellarwind on 28-Янв-14, 17:20
	Леньке наглядно объяснили, что убунта и так делает telinit u, а убивать все процессы и пытаться размонтировать фс в цикле это не лучшее решение, т.к. например если на этот момент примонтирована сетевая фс, которой все еще нужна сеть, смерть network-manager (как Леня предлагает) никак не поможет ей правильно отмонтироваться. Локальные ФС будут размонтированы, зато сетевые будут ошибками покрываться.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

9. "Анализ реализаций алгоритма остановки ОС в различных система..."	+15 +/–
Сообщение от McLeod095 (ok) on 28-Янв-14, 10:54
Сейчас опять начнется что systemd не нужен и нафиг это поделие. А ведь человек не только создал рабочий софт, но и не скрывает свои решения возникших проблем. Он не посоветовал что для решения проблемы возмите кусок из моего софта, или не предложил полностью на него перейти, он описал ситуацию которая возникает и описал решение которое ему показалось наиболее оптимальным и правильным. А в итоге сейчас в комментах в его адрес (да и в мой) полетят гнилые помидоры. Я кстати довольно часто видел как в CentOS 6 не всегда может быстро и нормально при выключении отмонтироваться /var, и знаю что проблема не надуманная.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	23. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от cmp (ok) on 28-Янв-14, 11:25
	Хм, частенько видел как система не могла загрузится, потому что не проходила проверку корневая фс, потому что, fsck / выдавал ошибку о том, что / - это директория. В большенстве случаев не разбирался, что да как, а заменял в скрипте fsck / на fsck.etx3 /dev/sda2. Да это тупо, зато на все про все 10 мин, а там уж пусть админы того сервера чешуться, а что же делать с системд в случае когда произойдет сбой во внутренней логике? Проблема в том, что идеальных решений не бывает и косячит будут и скрипты, и системд, но скрипты можно поправить, а с этим бинарным поделием, что прикажете делать? курить исходники? так может сразу нафиг?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	25. "Анализ реализаций алгоритма остановки ОС в различных система..."	–2 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 11:53
	> Хм, частенько видел как система не могла загрузится, потому что не проходила > проверку корневая фс, потому что, fsck / выдавал ошибку о том, > что / - это директория. Дистрибутив и версию вспомните? > В большенстве случаев не разбирался, что да как, а заменял в скрипте > fsck / на fsck.etx3 /dev/sda2. Да это тупо... Да, это тупо. > Проблема в том, что идеальных решений не бывает и косячит будут и > скрипты, и системд, но скрипты можно поправить, а с этим бинарным > поделием, что прикажете делать? курить исходники? так может сразу нафиг? google://sytemd+debugging
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	30. "Анализ реализаций алгоритма остановки ОС в различных система..."	+2 +/–
	Сообщение от cmp (ok) on 28-Янв-14, 12:21
	> Дистрибутив и версию вспомните? RPM base, последний раз было на каком-то встроенном в систему сканирования отпечатков пальцев в отделении полиции соседнего городка, альт может быть, но точно не помню. >> Проблема в том, что идеальных решений не бывает и косячит будут и >> скрипты, и системд, но скрипты можно поправить, а с этим бинарным >> поделием, что прикажете делать? курить исходники? так может сразу нафиг? > google://sytemd+debugging Да я даже знать не хочу как оно там работает, мне до звезды. Скрипты помогают мне жить, я могу написать хоть в консоле последовательность действий и пойти курить пока оно выполняется, или скажем переинициализировать сеть на серваке, или помудрить с iptables, зная что через 10 мин запустится скрипт который вернет все как было, и управление я не потеряю. А на кой черт мне отладка этого системд, я работаю в сфере эксплуатации, а не починки, как и большенство. Починкой занимаются студентики по вызову из объявлений в автобусах, но думаю даже им это нафиг не надо. Но изредка починять систему приходится, и ради этого "раз в пятилетку" - сидеть, гуглить, разбираться, да нахрен оно упало, если более мне эти знания не пригодятся, быстрее из бэкапа восстановить или заново поднять. Какбы я не против системд на вашем компьютере, но мне это не нужно, но разрабы же не станут поддерживать оба варианта, таким образом - кто не с нами, тот против нас. Ничего личного)))
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	32. "Анализ реализаций алгоритма остановки ОС в различных система..."	–2 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 12:28
	>> Дистрибутив и версию вспомните? > RPM base, последний раз было на каком-то встроенном в систему сканирования отпечатков > пальцев в отделении полиции соседнего городка, альт может быть, но точно > не помню. А в каком "скрипте" вы заменили "fsck / на fsck.etx3 /dev/sda2" вспомните? Или может быть приснилось? P.S.: хотя бы на fsck /dev/disk/by-uuid/xxx заменили, что-ли, если уж на то пошло...
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	43. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от cmp (ok) on 28-Янв-14, 13:30
	> А в каком "скрипте" вы заменили "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.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	44. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 13:37
	>> А в каком "скрипте" вы заменили "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. Назовете это "большинство"?
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	52. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от cmp (ok) on 28-Янв-14, 13:56
	>> 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> а тут нет
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	57. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 14:25
	>[оверквотинг удален] > тут фс на устройстве / определилась >>> 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
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	191. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от дуайт эйзенхауер on 29-Янв-14, 08:10
	> Да я даже знать не хочу как оно там работает, мне до звезды. Жесть какая. Таким уникумам вообще нельзя давать в руки что-либо сложнее лома. Даже чтобы копать лопатой желательно разбираться как она работает.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	40. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 13:28
	> google://sytemd+debugging будешь на ассемблере новую логику писать? ;)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	46. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 13:38
	>> google://sytemd+debugging > будешь на ассемблере новую логику писать? ;) А это к чему вообще?
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	68. "Анализ реализаций алгоритма остановки ОС в различных система..."	+2 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:38
	>>> google://sytemd+debugging >> будешь на ассемблере новую логику писать? ;) > А это к чему вообще? Ну, типа намек, что юниксвей состоит в постоянном переписывании системы инициализации каждым админом под себя. А сделать одну так, чтобы она работала - нельзя, виндyзятничество.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	117. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от chinarulezzz (ok) on 28-Янв-14, 18:31
	>>>> google://sytemd+debugging >>> будешь на ассемблере новую логику писать? ;) >> А это к чему вообще? > Ну, типа намек, что юниксвей состоит в постоянном переписывании системы инициализации каждым > админом под себя. Давно уже так:  sysvinit, openrc, Upstart, Runit, Daemontools, Launchd, Initng, systemd. > А сделать одну так, чтобы она работала - нельзя, виндyзятничество. sysvinit работала. Но делать еще одни прогрессивные плееры^W системы инициализации - типичные для кодеров действия. Bycicle, bycicle, bycicle. I want to ride my bycicle.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	181. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 22:30
	> sysvinit работала. initscripts: shutdown/reboot hangs after K03rsyslog http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734367 sysvinit-utils: /bin/pidof fails when there are stuck NFS mount points, preventing shutdown http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719273 initscripts: 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
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	187. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 29-Янв-14, 01:05
	>> sysvinit работала. > initscripts: F20: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s...
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	190. "Анализ реализаций алгоритма остановки ОС в различных система..."	–2 +/–
	Сообщение от ноним (ok) on 29-Янв-14, 07:33
	>>> 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...
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	192. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от ананим on 29-Янв-14, 08:15
	типа похтеринг, выступая с сабжем, проявил верх объективности? я за всю историю работы с различными системами инициализации (включая мак, солярис, юниксваре, ско опенскрвер,…) не имел столько проблем с монтированием различных ФС с не менее различных устройств, сколько за 7-9 месяцев знакомства с системд.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	204. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 29-Янв-14, 14:31
	>> F20: > Ну что же вы так однобоко: У него и так integer overflow случился, скорее всего.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	213. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Аноним (??) on 30-Янв-14, 11:03
	> F20: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s... Никто и не отрицает существование багов, связанных с systemd. Я лишь хотел сказать, что и sysvinit идеализировать не стоит, проблемы бывают везде, и я привел пару примеров только чтобы об этом напомнить. Михаил, я не сравнивал ни количество багов, ни их содержание, ни между проектами, ни между дистрибутивами, я указал только на их существование. Может Вы под впечатлением от каких-то других комментов так отреагировали? Проблемы, очевидно, бывают не только с systemd, иначе вряд ли бы кто-то упоминал простоту их решения как одно из достоинств sysvinit, что, если подумать, звучит сомнительно - пользователи предпочитают проекты, который не требует от них самих решения проблем, а просто работают, или по крайней мере оперативно решают возникающие проблемы в апстриме. Я не утверждаю, что systemd на данном этапе именно такой проект, тут вопрос в том, какой проект имеет больше шансов приблизиться к такому состоянию в обозримом будущем. Пока что точно известно лишь одно - у sysvinit была огромная фора по времени и это не слишком помогло, раз уж простота решения проблем *самими пользователями* все еще упоминается как одно из основных достоинств. И еще, я говорил не о популярности проектов вообще, а о популярности *среди разработчиков*, и я не знаю почему Вы предпочли не заметить этот момент. Может не стоило так горячиться при виде слова "популярность"? Разработчики, как правило, гораздо лучше понимают реальные плюсы и минусы различных решений, чем все прочие, и они не руководствуются хвалебными или ругательными отзывами в "бложиках", они своими глазами видят все достоинства и недостатки, поскольку они напрямую с ними имеют дело. Суть в том, что проект без пользователей вполне может развиваться, а вот проект без разработчиков - вряд ли. И когда дистрибутив выбирает проект, на который он будет полагаться в ближайшем будущем, очевидно, что количество имеющихся и потенциальных будущих разработчиков этого проекта - достаточно важный фактор, ведь вряд ли кто-то захочет завязывать будущее своего дистрибутива на мертвый проект над которым никто не работает. Именно об этом я и говорил, а не о популярности среди пользователей и комментаторов на форумах - это в данном вопросе вообще практически не важно. Опять же, уточню на всякий случай, я не утверждаю, что sysvinit - мертвый проект, но прикинуть шансы на дальнейшее развитие всех альтернатив и учитывать это при выборе все-таки, наверное, стоит.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	216. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Michael Shigorin (ok) on 30-Янв-14, 17:20
	>> F20: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s... > Никто и не отрицает существование багов, связанных с systemd. Так я для удобства и привёл скромную ссылочку :) > Может Вы под впечатлением от каких-то других комментов так отреагировали? Скорее справедливости ради (tm). > Я не утверждаю, что systemd на данном этапе именно такой проект, > тут вопрос в том, какой проект имеет больше шансов приблизиться > к такому состоянию в обозримом будущем. Думаю, конкретно у systemd шансов было бы больше при... внедрении "по-хорошему", а не "добрым словом и пистолетом" (ck/pk, gnome3, > Пока что точно известно лишь одно - у sysvinit была огромная > фора по времени и это не слишком помогло, В смысле не помогло?  Работает себе. > раз уж простота решения проблем *самими пользователями* все еще упоминается > как одно из основных достоинств. А это и есть одно из основных достоинств _инструмента_, предназначенного для решения широкого и малопредсказуемого заранее круга задач. > И еще, я говорил не о популярности проектов вообще, а о популярности > *среди разработчиков*, и я не знаю почему Вы предпочли не заметить > этот момент. Может не стоило так горячиться при виде слова "популярность"? Вообще-то заметил и отвечал именно в этом ключе.  Если что, AFAIK первые образы альта на systemd я и выпускал. > Разработчики, как правило, гораздо лучше понимают реальные плюсы и минусы различных > решений, чем все прочие, и они не руководствуются хвалебными или ругательными > отзывами в "бложиках", они своими глазами видят все достоинства и недостатки, > поскольку они напрямую с ними имеют дело. Несколько сложнее и вплоть до того, что стадные эффекты также имеют место быть (а то и руководство фирмы/проекта). > Суть в том, что проект без пользователей вполне может развиваться Не-а.  Писать и не пользоваться самому -- верный путь к деградации проекта. > [...] очевидно, что количество имеющихся и потенциальных > будущих разработчиков этого проекта - достаточно важный фактор Это может показаться странным, но мне оно несущественно: куда важнее степень работоспособности проекта, характер развития и вменяемость апстрима.  За других, разумеется, не говорю. > но прикинуть шансы на дальнейшее развитие всех альтернатив и учитывать это > при выборе все-таки, наверное, стоит. Разумеется.
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

	51. "Анализ реализаций алгоритма остановки ОС в различных система..."	+3 +/–
	Сообщение от Michael Shigorin (ok) on 28-Янв-14, 13:55
	> google://sytemd+debugging Спасибо, дорогой.  А теперь примените к залипанию без диагностики на выключении.  Или к минутному примерно таймауту на складывании пользовательской сессии, которого и не просили.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	58. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:26
	> А теперь примените к залипанию без диагностики на выключении. http://freedesktop.org/wiki/Software/systemd/Debugging/#inde... Не? > Или к минутному примерно таймауту на складывании пользовательской сессии, которого и не просили. Видимо, надо писать багрепорт.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	108. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от jOKer (ok) on 28-Янв-14, 17:30
	> Видимо, надо писать багрепорт. Именно так. И ждать... долго ждать. А если хочется ждать мало, то платить. Много платить. И, - вы удивитесь, платить РедХат и Поцтерингу. Собственно это и есть главная цель RH: увеличить маржу за тех. поддержку. А теперь вопрос: а на черта мне ждать и платить, если я на OpenRC любой баг сам за 20 минут подлатаю, а? Ну, если нарвусь конечно... потому что за последние три года НИ РАЗУ не было ни одного! А все что мне пришлось там править сводилось к личной кастомизации системы.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	113. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 18:03
	>> Видимо, надо писать багрепорт. > Именно так. И ждать... долго ждать. А если хочется ждать мало, то > платить. Много платить. И, - вы удивитесь, платить РедХат и Поцтерингу. > Собственно это и есть главная цель RH: увеличить маржу за тех. > поддержку. А в OpenRC видать баги моментально исправляют? > А теперь вопрос: а на черта мне ждать и платить, если я > на OpenRC любой баг сам за 20 минут подлатаю, а? Ну, > если нарвусь конечно... потому что за последние три года НИ РАЗУ > не было ни одного! А все что мне пришлось там править > сводилось к личной кастомизации системы. Валяйте: https://bugs.gentoo.org/buglist.cgi?component=OpenRC&product... Hosted Projects&resolution=---   86*20/60 ~ 29 часов вам походу хватит.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	208. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 29-Янв-14, 15:47
	>> А теперь примените к залипанию без диагностики на выключении. > http://freedesktop.org/wiki/Software/systemd/Debugging/#inde... Спасибо, на эту страничку не натыкался.  Плохо ещё и то, что параллелизм -- рассадник гонок, а вылавливать редко встречающееся или каждый раз готовить полигон для отлова -- извините, некогда. >> Или к минутному примерно таймауту на складывании пользовательской сессии, >> которого и не просили. > Видимо, надо писать багрепорт. Багрепорт-то да, только вот там висяки в основном получаются, похоже.  К тому же в 204 этой проблемы не было, соответствующая багофича была добавлена позже. Т.е. есть проблемы, по которым есть смысл тратить время -- а есть такие, которые в проекте выбраны по постановке задачи.  Залипания при полностью динамическом разрешении зависимостей в рантайме каждый раз -- именно из этой оперы. PS re #61: необязательно; по мере наличия свободного времени.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	61. "Анализ реализаций алгоритма остановки ОС в различных система..."	–2 +/–
	Сообщение от ноним (ok) on 28-Янв-14, 14:30
	>> google://sytemd+debugging > Спасибо, дорогой.  А теперь примените к залипанию без диагностики на выключении. journalctl -b -1 , не? И если оно один раз зависло, зависнет и второй раз, так? >  Или к минутному примерно таймауту на складывании пользовательской сессии, которого > и не просили. Во-первых - ожидание завершения юнитов в systemd - 90 сек., а не минута. Во-вторых - поподробнее, пожалуйста (желательно с пруфом на багтрекер в апстриме)
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	29. "Анализ реализаций алгоритма остановки ОС в различных система..."	+8 +/–
	Сообщение от Reinar (ok) on 28-Янв-14, 12:12
	> что для решения проблемы возмите кусок из моего софта хе-хе, а ведь не выйдет, даже если и очень захочется: 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 к интеграции в другие дистрибутивы, принимая во внимание их лицензионную политику.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	81. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:55
	> Я вообще не понимаю, как можно рассматривать хоть что-то от Canonical к > интеграции в другие дистрибутивы, принимая во внимание их лицензионную политику. А дебианщики уже размахнулись поддерживать патчи для портабельности upstart out-of-tree, в виде патчей к дебиановскому пакету :) Наверное, будет забавано, если учесть, что upstart тоже нехило привязан к линуксу, и придется переписать чуть ли половину кода.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

11. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
Сообщение от Аноним (??) on 28-Янв-14, 11:07
А Поттеринг не планирует в ближайшее время убрать less из systemctl?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Анализ реализаций алгоритма остановки ОС в различных система..."	+4 +/–
	Сообщение от Fracta1L (ok) on 28-Янв-14, 11:09
	А зачем?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	17. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от ноним (ok) on 28-Янв-14, 11:15
	> А Поттеринг не планирует в ближайшее время убрать less из systemctl? alias systemctl='systemctl --no-pager'
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	31. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от freehck (ok) on 28-Янв-14, 12:22
	Ага, давайте его ещё и из man уберём.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	42. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Аноним (??) on 28-Янв-14, 13:30
	> Ага, давайте его ещё и из man уберём. не, из man не надо, да и убирается легко, достаточно перенаправить вывод не в терминал, типа: man xxx | cat
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	71. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:42
	> не, из man не надо, да и убирается легко, достаточно перенаправить вывод > не в терминал, типа: man xxx | cat А systemctl xxx | cat писать низзя?
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

21. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
Сообщение от Нанобот (ok) on 28-Янв-14, 11:19
сугубо технические проблемы работы одной функции системы. не тянет оно на "главные новости"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "Анализ реализаций алгоритма остановки ОС в различных система..."	–2 +/–
Сообщение от Аноним (??) on 28-Янв-14, 12:02
забавно, у меня вот при использовании lvm, luks, raid и прочих nfs такой проблемы ни разу не возникало. Леннарт опять породил решение в поисках проблемы?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	134. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от anonymous (??) on 28-Янв-14, 19:28
	да, ты его разоблачил! спасибо тебе, отважный защитник!
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

35. "Анализ реализаций алгоритма остановки ОС в различных система..."	+3 +/–
Сообщение от Xaionaro (ok) on 28-Янв-14, 12:37
из 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!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	72. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:43
	>> 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! Фанбои бесятся :)
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	86. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от Xaionaro (ok) on 28-Янв-14, 15:02
	> Фанбои бесятся :) Фанбои фанатеющие по чему?
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	94. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Аноним (??) on 28-Янв-14, 15:48
	> Фанбои фанатеющие по чему? Там есть своя политтусовка вокруг OpenRC.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	97. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Xaionaro (ok) on 28-Янв-14, 16:00
	> Там есть своя политтусовка вокруг OpenRC. И каких политических взглядов они придерживаются и интересы какой компании/государства/etc они представляют?
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	96. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от Lain_13 (ok) on 28-Янв-14, 15:53
	По нафиг никому не нужному 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 хранить бэкап другого такого раздела без сжатия или шифрации, то при перестройке дерева вместо файла бэкапа можно получить странное нечто, состоящее из содержимого диска и бэкапа вместе.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	159. "Анализ реализаций алгоритма остановки ОС в различных..."	+1 +/–
	Сообщение от arisu (ok) on 28-Янв-14, 20:23
	> Похороните вы его уже, а не тыкайте палочкой. спасибо. твоего очень ценного мнения очень не хватало. как же без твоих-то ценных указаний? «хоронильщик», йопт…
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	182. "Анализ реализаций алгоритма остановки ОС в различных..."	–1 +/–
	Сообщение от Lain_13 (ok) on 28-Янв-14, 22:43
	Всегда пожалуйста, был очень рад помочь, обращайтесь.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	183. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от pv47 (ok) on 28-Янв-14, 23:26
	> Из-за этого если на разделе с raiserfs хранить бэкап другого такого раздела без сжатия или шифрации, то при перестройке дерева вместо файла бэкапа можно получить странное нечто, состоящее из содержимого диска и бэкапа вместе. Ага! Попался! Давно хотел спросить (не ради смеху, а, правда, интересно) у кого-нибудь, хаящего рейзер по этой причине. Как данная проблема решается в других фс (хотя бы в одной из ext{2,3,4}, xfs)? Как вообще утилита, получающая кусок байтовой последовательности, может понять, что является основной файловой системой, а что - файловой системой образа, лежащего на основной системе?
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	157. "Анализ реализаций алгоритма остановки ОС в различных..."	+3 +/–
	Сообщение от arisu (ok) on 28-Янв-14, 20:22
	>> Фанбои бесятся :) > Фанбои фанатеющие по чему? по системды. прямо тут, на опеннете. как только их в очередной раз тычут носом в то, что системды — кусок говна, они начинают кричать про «haters gonna hate», «системды-ненавистников» и прочую ерунду.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	211. "Анализ реализаций алгоритма остановки ОС в различных..."	+/–
	Сообщение от Аноним (??) on 29-Янв-14, 21:54
	Забыл что они ещё рассказывают про не читаемые портянки скриптов, бричку и космолёт ну и сами не пользуются системд.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

45. "Анализ реализаций алгоритма остановки ОС в различных система..."	+4 +/–
Сообщение от anonymous (??) on 28-Янв-14, 13:37
К сожалению, при всех описанных плюсах systemd, он все еще не предназначен для использования в в большинстве ситуаций, отходящих от стандартных use-case. До сих пор нет возможности оставить от systemd только систему инициализации, убрав все эти journald и другие навязанные сервисы. Напоминает галочки в виндовых инсталляторах - "установить яндекс.бар, бесплатный антивирус, шахматы и поэтесс+", активированные по умолчанию.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	75. "Анализ реализаций алгоритма остановки ОС в различных система..."	–7 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 14:51
	> К сожалению, при всех описанных плюсах systemd, он все еще не предназначен > для использования в в большинстве ситуаций, отходящих от стандартных use-case. Наоборот :) systemd изначально разработан модульным и расширяемым, в отличие от скриптов, у разработчиков которых всегда есть отмазка "если пользователю надо, он перепишет". В результате мы имеем то, что имеем - при отклонении от стандартных use case приходится лезть в дебри скриптов, вместо того, чтобы добавить один-два простых юнита, как в systemd. > До сих пор нет возможности оставить от systemd только систему инициализации, убрав > все эти journald и другие навязанные сервисы. Нельзя отключить только journald и udev. Потому что кто-то должен обрабатывать обращения программ к системному логу (хотя бы в режиме заглушки) и события устройств. Все остальное можно отключить. > Напоминает галочки в виндовых инсталляторах - "установить яндекс.бар, бесплатный антивирус, шахматы и поэтесс+", активированные по умолчанию. Почему, как только что-то работает без траха - так сразу "винда"?
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	89. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от ананим on 28-Янв-14, 15:13
	>Почему, как только что-то работает без траха - так сразу "винда"? Э-э-э, потому что это откровенная брехня?
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	93. "Анализ реализаций алгоритма остановки ОС в различных система..."	+2 +/–
	Сообщение от anonymous (??) on 28-Янв-14, 15:39
	> Наоборот :) > 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 в соседней теме - это не развитие, это стагнация. Те вещи, которые уже работали, давно, хорошо работали, заменяются новыми и неработающими. А то, чего не было - так и нет до сих пор, уже десяток лет.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	99. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от ананим on 28-Янв-14, 16:07
	>При этом, 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-х виноват уже не такая тривиальная задача, как со скриптами.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	160. "Анализ реализаций алгоритма остановки ОС в различных..."	+2 +/–
	Сообщение от arisu (ok) on 28-Янв-14, 20:25
	системды-специфичное апи вообще нафиг не нужно.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	161. "Анализ реализаций алгоритма остановки ОС в различных система..."	–1 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 20:34
	>Напоминает галочки в виндовых инсталляторах - "установить яндекс.бар, бесплатный антивирус, шахматы и поэтесс+", активированные по умолчанию. Угу, только там галки можно снять и ненyжно не ставить.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

95. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
Сообщение от Аноним (??) on 28-Янв-14, 15:48
Да, улучшающееся качество статей на опеннете не может не радовать. Аноним молодец!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

98. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
Сообщение от Xasd (ok) on 28-Янв-14, 16:02
> Примечание: Интересно, что проблема перемонтирования корневой файловой системы, похоже, присутствует не только в Upstart, но и в OpenRC — там она выражается в зависании процесса выключения с сообщением «failed because we are using /», например, после запуска prelink. Несмотря на то, что разработчики OpenRC отмечают такие ошибки, как UNCONFIRMED, опытные пользователи Gentoo знают о проблеме, и рекомендуют добавлять команду «telinit u» в скрипт выключения ОС — /etc/init.d/mount-ro. вся суть велосипедостроения -- в одном обзаце :) опытные пользователи оказались умнее разработчиков :-) [хотя -- отдаёт желтезной]
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	101. "Анализ реализаций алгоритма остановки ОС в различных система..."	+2 +/–
	Сообщение от ананим on 28-Янв-14, 16:14
	>[хотя -- отдаёт желтезной] И ещё какой. Согласитесь, что это >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
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	104. "Анализ реализаций алгоритма остановки ОС в различных система..."	–2 +/–
	Сообщение от anonymous (??) on 28-Янв-14, 17:07
	Я специально для Вас выпишу основные пункты новости: Upstart повреждает ФС в редких случаях из-за проблем с перемонтированием корневой файловой системы, что решается перезапуском upstart. OpenRC страдает от той же проблемы с перемонтированием, что опять же решается перезапуском OpenRC. Не благодарите.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	110. "Анализ реализаций алгоритма остановки ОС в различных система..."	+5 +/–
	Сообщение от ананим on 28-Янв-14, 17:51
	Забавно, мне не нужно было читать новость, чтобы убедится, что когда повис намертво 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
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	131. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
	Сообщение от Xasd (ok) on 28-Янв-14, 19:18
	> Комментарии потеринга (хотя бы в этих багах) приветствуются. Вместо этого он решил > поучаствовать в багтрэккерах апстарта и опенрк? > Как это мило! :D очевидно, перед тем как комментировать -- он решил посмотреть как это сделано у других :)
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	136. "Анализ реализаций алгоритма остановки ОС в различных система..."	+2 +/–
	Сообщение от ананим on 28-Янв-14, 19:32
	Самое забавное, что на свои баги у него нет времени, но написать столь развёрнутое эссе по поводу upstart оно нашлось.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	170. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
	Сообщение от Аноним (??) on 28-Янв-14, 21:26
	Пока весь opennet читает, у него есть время подумать )))))))) Сунь-цзы  нервно курит  за углом ;)
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

176. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
Сообщение от кевин on 28-Янв-14, 21:44
эх жаль лёня отлично поработал и доходчиво рассказал о сложной проблеме, но никто не будет читать...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

201. "Анализ реализаций алгоритма остановки ОС в различных система..."	–2 +/–
Сообщение от Kodir (ok) on 29-Янв-14, 13:55
"Если в то время, когда файл оставался открытым на чтение для некоторого процесса, этот файл был перезаписан целиком (удален и создан заново), процесс продолжает работать со старой версией файла" *FACEPALM* Мне одному кажется, что маразм породил маразм? Если файл открыт на чтение и кто-то пытается файл прибить, есть два _разумных_ варианта: 1. Файл прибиваем, читателю возвращаем ошибку. 2. Убивателю возвращаем ошибку, файл остаётся жить. При этом это не взаимоисключающие пункты, т.к. в системе можно поддерживать оба. Например, для tail подойдёт вариант 1, а для /dev/timer - 2.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	203. "Анализ реализаций алгоритма остановки ОС в различных система..."	+2 +/–
	Сообщение от Andrey Mitrofanov on 29-Янв-14, 14:31
	> *FACEPALM* > Мне одному кажется, что маразм породил маразм? Если файл открыт на чтение > и кто-то пытается файл прибить, есть два _разумных_ варианта: Это не разумные варианты, это _твои _виндовые привычки. Велкам то зе нью брэйв йуникс уорлд, муа пети!
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

210. "Анализ реализаций алгоритма остановки ОС в различных система..."	+1 +/–
Сообщение от myhand (ok) on 29-Янв-14, 17:34
> Примечание: Интересно, что проблема перемонтирования корневой файловой системы, похоже, > присутствует не только в Upstart, но и в OpenRC А почему неинтересно то, что она отсутствует в sysvinit? Любим геройский решать проблемы, которые сами и создали?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

214. "Анализ реализаций алгоритма остановки ОС в различных система..."	+/–
Сообщение от Аноним (??) on 30-Янв-14, 13:57
я просто оставлю здесь это 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 #
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	215. "Анализ реализаций алгоритма остановки ОС в различных..."	+/–
	Сообщение от arisu (ok) on 30-Янв-14, 14:13
	> я просто оставлю здесь это жуть какая выше нарисована. 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 совместимости из коробки.
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема