The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

"Анализ реализаций алгоритма остановки ОС в различных система..."  +/
Сообщение от 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 email 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 email(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 email(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 email(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 email(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 email(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 email(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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру