LINUX.ORG.RU

Arch Linux перешёл на systemd полностью

 ,


0

5

С сегодняшнего дня все новые установки Arch Linux будут поставляться с systemd по умолчанию, что означает завершение перехода на systemd. Поддержка initscripts как пакета и системы загрузки сохранится для совместимости на неопределённое время.

Изменение заключается в добавлении пакета systemd-sysvcompat в группу base, которая автоматически полностью устанавливается всем новым пользователям Арча.

Не все пакеты ещё готовы к переходу, так что тем, кто не может написать к ним systemd-юнит, предлагается установить initscripts и использовать массив DAEMONS в /etc/rc.conf (пакет нужно установить для поддержки в systemd чтения этого файла).

Существующие системы могут перейти на systemd вручную.

>>> Подробности

Ответ на: комментарий от AX

А причём здесь дистрибутив

А притом, что поставив, скажем, ubuntu можно иметь самый свежий софт из ppa без пересмотра базовых системных настроек. Не дело это — менять принципы настройки базовых вещей каждые полгода.

Конечно, BSD в этом смысле рулит, там мануалы по настройке всего и вся актуальны, как правило, не менее трёх лет.

Lothlorien ★★★
()
Ответ на: комментарий от Lothlorien

По теме: посоветуйте что-нибудь с bsd-style init, кроме Slackware.

CRUX. Но там свои тараканы.

sergv
()
Ответ на: комментарий от Lothlorien

переход на HAL, то переход с HAL на udev

без пересмотра базовых системных настроек

Хочешь сказать, что в убунте до сих пор static /dev и все устройства нужно монтировать вручную из рутовой консоли?

AX ★★★★★
()
Ответ на: комментарий от anonymous

Парни, намекните хоть накукуй нужен этот consolekit? Я уже и так смотрел и этак читал. Нихера не понял его нужности.

thing
()
Ответ на: комментарий от anonymous

Твою сказку времен пре-альфа версий тут все помнят наизусть, не позорься уже.

Это не сказка. 2-3 месяца назад ставил «напосмотреть» гнум3, вместе с ним притянулся pulseaudio. Естественно, после запуска ни в одной программе звука не было. Снёс пульс — звук появился. Вывод?

AX ★★★★★
()
Ответ на: комментарий от jackill

Смешно.

Ну это факт, смешно вам или нет. После изменения конфигурации все приложения, использующие ALSA, нужно перезапускать.

И настройки сохранять не умеет, да?

Э?

А пульс работает через божественный драйвер.

Архитектура PA позволяет менять почти любые параметры на ходу. Я не то чтобы сильно люблю это поделие, но факт есть факт.

Homura_Akemi
()
Ответ на: комментарий от AX

Хочешь сказать, что в убунте до сих пор static /dev и все устройства нужно монтировать вручную из рутовой консоли?

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

Lothlorien ★★★
()
Ответ на: комментарий от ZenitharChampion

Леннарт Поттеринг и его реализация Zeroconf.
Леннарт Поттеринг и его звуковой сервер
Леннарт Поттеринг и его системный init

Обещают 7 частей?

Я ошибаюсь или в последней части все умерли? Тогда зачёт.

thing
()
Ответ на: комментарий от AX

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

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

anonymous
()

Мои соболезнования пользователям Арча. Надеюсь Убунта не перейдет на на systemd, не зря же они свой upstart пилили.

FreeLiver ★★★
()
Ответ на: комментарий от Lothlorien

да и вообще в любых lts

Даже я знаю, что в убунте не все релизы имеют статус LTS… *посмотрев в википедию* а только те, которые выходят раз в 2 года.

базовая система не пересматривается при обновлениях

Извини, но это чушь. Если новая версия какого-то приложения использует udisks вместо hal, то при обновлении любого дистра оно по зависимостям притянет udisks. Я очень хорошо помню плачь убунтоидов на этом форуме, когда в xorg поломали чтение xorg.conf.

Попробуй обновиться с 7.0x до 12.0x. Сразу поймёшь, о чём я говорю. :)

AX ★★★★★
()

полёт нормальный

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

SKEW
()
Ответ на: комментарий от Lothlorien

Ты сравниваешь lts и rolling релиз по критерию

базовая система не пересматривается при обновлениях

Это довольно странно.

wq
()
Ответ на: комментарий от Eddy_Em

Я и не говорю что не полезная. Прибиваем гвоздями systemd к udev(который во всех дистрибутивах), и ВНЕЗАПНО systemd появляется во всех дистрибутивах.

wq
()
Ответ на: комментарий от wq

Это довольно странно.

Это FreeBSD, где порты обновляются отдельно от БС.

Lothlorien ★★★
()
Ответ на: комментарий от AX

Попробуй обновиться с 7.0x до 12.0x. Сразу поймёшь, о чём я говорю. :)

Я понимаю, но и понимаю, что это происходит не каждый день ;)

Lothlorien ★★★
()
Ответ на: комментарий от anonymous

Всем плющемся на systemd, welcome to http://linexp.ru/

Ба! Так это ж SLOR!

На systemd плюются потому, что он заменяет надёжную, проверенную, простую и быструю систему на глючную, непроверенную, сложную и тормозную. Хорошая подсистема запуска дохнет. И те, кто на него плюются, на SLOR не пойдут, там итак уже всё сдохло.

anonymous
()
Ответ на: комментарий от Lothlorien

Я понимаю, но и понимаю, что это происходит не каждый день ;)

Дык, и в арче не каждый день. Это просто временное обострение у поттерингофанов.

AX ★★★★★
()

Интересно! У дружище как раз Arch стоит - Хоть гляну что это =)))

gBopHuk
()
Ответ на: комментарий от ekzotech

на бис

Объясни суть своих претензий к systemd.

Я за него.

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

А к systemd претензия в том, что он — худшее, что могли выбрать арчеводы для init-системы. Да, то, что было в арче, ужасно. Но его можно было улучшить, хотя бы добавив обработку LSB-headers для параллельного запуска. Если не хотелось изобретать свой, можно было взять готовый openrc из gentoo, старенький initrg из suse или адаптировать под себя параллельную загрузку из дебиана. Но они выбрали худший возможный вариант — сломать всё и переписать заново используя самую сложную и кривую систему из всех, что можно было выбрать.

Если бы systemd работал ­— все были бы рады. Любая программа идеальна, пока она делает то, что тебе надо. В теории. Но на практике таких программ не бывает. Всегда бывает нужно изменить что-то, оптимизировать под себя настройки, добавить собственный скрипт для автозапуска или поправить один из существующих. Наконец иногда вылазят баги после апдейта, которые надо быстро поправить и работать дальше. Арчеводы, как никто другой, должны об этом знать. Но поиск багов systemd — это ужас, как его настраивать знают не многие, а отлаживать его умеют единицы.

Простой пример: если заменить /tmp на симлинк в /home/tmp, то systemd сносит крышу и система не стартует. Как это починить? Как найти причину и исправить её?

Раньше считалось, что арч хорош потому, что он KISS. Но использование вместо init-а велосипедокомбайна из (неполный список) init-демона, syslog-а, udev, cron, dbus, (x)inetd, readahead, ulatencyd, kdm/gdm/xdm, consolekit, sethostname, mount и http-сервера говорит о том, что арч больше не KISS. Какие ещё есть причины им пользоваться?

anonymous
()
Ответ на: комментарий от thing

Я бы срадостью, но сам не понимаю. А если пытаться найти инфу то везде написано что оно устарело и более не нужно.

anonymous
()
Ответ на: полёт нормальный от SKEW

Малаца. Сколько серверов первёл на systemd? Как организовал хранение логов? Проверку их целостности? Что используешь для анализа логов. Как перенастроил fail2ban, например? Что дописал в русскую вики в конце концов? Как с наличием unit'ов под apache, *ftpd, nginx, lighttpd, sshd и подобное? как со всем этим теперь работает zabbix или что ты там вместо него крутишь?

anonymous
()
Ответ на: на бис от anonymous

Но использование вместо init-а велосипедокомбайна из (неполный список) init-демона, syslog-а, udev, cron, dbus, (x)inetd, readahead, ulatencyd, kdm/gdm/xdm, consolekit, sethostname, mount и http-сервера

Список очень неполный. Из наиболее ярких велосипедов стоит также упомянуть: обвертку вокруг fsck, куски acpi, login/session manager, tmpwatch, date/ntp (systemd-timedated), cryptsetup, locales, kbd (setfont, loadkeys), sysctl, modprobe, ulimit, cat (systemd-cat), diff и sleep (да, есть systemd-sleep, хе-хе-хе :)) И этот список постоянно растёт.

anonymous
()
Ответ на: комментарий от Homura_Akemi

Архитектура PA позволяет менять почти любые параметры на ходу. Я не то чтобы сильно люблю это поделие, но факт есть факт.

В альсе тоже можно менять все налету.

jackill ★★★★★
()
Ответ на: комментарий от thing

Парни, намекните хоть накукуй нужен этот consolekit? Я уже и так смотрел и этак читал. Нихера не понял его нужности.

ConsoleKit — это был большой шаг вперёд в юзабельности линукс-систем из коробки. Раньше после установки системы нужно было долго настраивать права пользователя, добавлением его в разные группы и т.д. ConsoleKit взял это на себя. Его задача — управление доступом к специфическим для юзера ресурсам с помощью POSIX ACL.

Представь себе, что у тебя есть машина в клубе/офисе/универе, на которую могут логиниться разные пользователи, причём делать это могут и локально в иксах и по ssh. Очевидно, что если пользователь запустит mp3-плеер, то он должен услышать звук из колонок.

В обычной системе это бы зависело от прав на shm ALSA и файлы /dev/snd/*, и пришлось бы давать доступ к этим файлам всем, кто может залогиниться на эту машину. Но тогда залогиненный по ssh юзер мог бы мешать локально сидящему другому юзеру играя всякие гадости через колонки.

ConsoleKit решал эту проблему. Не нужно было вручную добавлять себя в группы audio, video, tuner, cdrom и floppy. Когда пользователь локально логинится в иксы, он давал ему права на нужные файлы, а когда пользователь вылогинивался — отбирал их. Также он управлял ресурсами для функции Switch User (есть в меню в любом нормальном DE) и для multiseat-систем (два монитора, две клавиатуры, две мыши, один системник). Хорошая была штука...

anonymous
()
Ответ на: комментарий от x0r

Когда ж уже в генточку запулят заместо б*гомерзкого openrc.

systemd есть в портаже, и вы вольны устанавливать его или нет: «Gentoo is about choice. If you like systemd, its in the tree, use it. If you don't like it, don't» - взято отсюда http://forums.gentoo.org/viewtopic-t-937778-highlight-systemd.html .

Гента замечательна тем, что это ваш выбор, ваша система, а не система дяди Пети или дяди Космонавта. Более того, она гораздо удобнее для новичков, чем Арч ;) Так что милости просим всех. Единственное кажущееся неудобство - время, необходимое на сборку пакетов, но, поверьте, это неудобство потревожит вас всего лишь один раз при установке (хотя базовая система ставится очень быстро, а время уходит на сборку того же КДЕ и libreoffice :)), а далее оно проходит соверщенно незаметно, потому что гентовские инструменты весьма удобны и просты в использовании и сводят усилия пользователя по поддержанию дистра в постоянно обновленном состоянии к минимальным :)

Арчеделам - позор за лишение своих пользователей права выбора!

GluckMan ★★★
()
Ответ на: комментарий от GluckMan

Гента ... гораздо удобнее для новичков, чем Арч ;)

Почему ты так считаешь?

anonymous
()
Ответ на: комментарий от anonymous

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

Причем, если будет SSD, то разницы никто не заметит никак. А если будет тяжелый сервис, то машина будет стоять раком, несмотря на мультизагрузку, пока этот тяжелый сервис не прогрузится. И толку от веселеньких обоев никакого.

Может, у поттеринга машина постоянно падает и он решил ускорить себе загрузку?

jackill ★★★★★
()
Ответ на: комментарий от Polugnom

Не забыл - я ему выделил первый пункт «реализация Zeroconf». На Википедии посмотрел в обобщённом толковании термина Avahi.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)

Я вот читаю этот шедевр и изумление во мне растет стремительными темпами.

The message data is generally not authenticated, every local process can claim to be Apache under PID 4711, and syslog will believe that and store it on disk.

Интересно, а что с этим делает systemd? Думаю, что-то страшное.

The data logged is very free-form. Automated log-analyzers need to parse human language strings to a) identify message types, and b) parse parameters from them. This results in regex horrors, and a steady need to play catch-up with upstream developers who might tweak the human language log strings in new versions of their software. Effectively, in a away, in order not to break user-applied regular expressions all log messages become ABI of the software generating them, which is usually not intended by the developer.

С одной стороны он, конечно, прав - приходиться парсить рэгэкспами. А с другой стороны, программы должны писаться так, чтобы их мог прочитать человек, а уж потом скомпилить машина. То же касается и логов - сначала читает человек, потом уже машина. Машина может распарсить лог? Тогда какие проблемы? Сложно изучать регэксп? А что, написать юнит для этой хреноты, да еще и правильно, легче? А потом все в этот логгер завести?

The timestamps generally do not carry timezone information, even though some newer specifications define support for it.

Это ужасно. И те, кому это важно, не нашли решения и плачут, сидя с калькулятором и прибавляя часы.

Syslog is only one of many log systems on local machines. Separate logs are kept for utmp/wtmp, lastlog, audit, kernel logs, firmware logs, and a multitude of application-specific log formats. This is not only unnecessarily complex, but also hides the relation between the log entries in the various subsystems.

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

Reading log files is simple but very inefficient. Many key log operations have a complexity of O(n). Indexing is generally not available.

Вот тут хотелось бы увидеть выкладки. Кто читает, что читает. И чем ему базы не угодили. Хотя... базы могли не угодить, ибо они точно не поднимутся на этапе загрузки ядра а логгер, как я понимаю, должен стартовать до этого момента (офигеть - скольким единицам нужен ядерный лог?).

The syslog network protocol is very simple, but also very limited. Since it generally supports only a push transfer model, and does not employ store-and-forward, problems such as Thundering Herd or packet loss severely hamper its use.

Честно скажу, я хз что это. :)

Log files are easily manipulable by attackers, providing easy ways to hide attack information from the administrator

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

Access control is non-existent. Unless manually scripted by the administrator a user either gets full access to the log files, or no access at all.

Да неужели? Странно. А я видел чтение только некоторых логов (в той же федоре) и еще и не во всех каталогах. Он под рутом сидит, что ли?

The meta data stored for log entries is limited, and lacking key bits of information, such as service name, audit session or monotonic timestamps.

Я, конечно, извиняюсь, но если я лезу в лог, скажем, иксов, не говорит ли это мне о том, что это лог иксов? А лог mysql - вроде как лог mysql. Ладно, тут же есть админы - вы сильно скучаете по этим вещам?

Automatic rotation of log files is available, but less than ideal in most implementations: instead of watching disk usage continuously to enforce disk usage limits rotation is only attempted in fixed time intervals, thus leaving the door open to many DoS attacks.

Атака переполнением пула логов, что ли?

Rate limiting is available in some implementations, however, generally does not take the disk usage or service assignment into account, which is highly advisable.

Я думаю, он проблему придумал сам после того, как системд стала спамить в логи.

Compression in the log structure on disk is generally available but usually only as effect of rotation and has a negative effect on the already bad complexity behaviour of many key log operations.

Каких операций? Что не так? Почему никто не жаловался?

Classic Syslog traditionally is not useful to handle early boot or late shutdown logging, even though recent improvements (for example in systemd) made this work.

На кой болт-то?

Binary data cannot be logged, which in some cases is essential (Examples: ATA SMART blobs or SCSI sense data, firmware dumps)

Ммм. Точно? Совсем-совсем? Но очень надо?

During the development of systemd the limitations of syslog became more and more apparent to us.

«Странно, » - подумал лось. «Я все пью, пью, а мне все хуже и хуже».

For example: one very important feature we want to add to ease the administrator’s work is showing the last 10 lines (or so) of log output of a service next to the general service information shown by “systemctl status foo.service”.

Фак, зачем это, если сервис здоров? А если болен, мы уже в логе. И почему 10? Больше в консоль не влезло?

Implementing this correctly for classic syslog is prohibitively inefficient, unreliable and insecure: a linear search through all log files (which might involve decompressing them on-the-fly) is required, and the data stored might be manipulated, and cannot easily (and without races) be mapped to the systemd service name and runtime.

Все же сначала надо было заставить его поработать админом пару лет.

jackill ★★★★★
()
Ответ на: комментарий от AX

Это в мире линукса никакой стабильности нет.

точно, вот у меня вин 8 про (активированная) и всё просто работает (it just works dude)
никаких тебе артефактов в кедах после обновления на 9-ую ветку месы (вначале на 9пре<тут_дата> появились, думал с релизом всё уйдет, ушли в такой явной форме, но появляются при перетаскивании терминала :-/ ), никаких тебе безпричинных ступоров на loading initial ramdisk, которые исправились переустановкой груба2 (не пересборка, а именно переинсталл: grub2-install --target=x86_64-efi )
пи.ся. гента

linux-v0id
()
Ответ на: комментарий от Lothlorien

На это нет времени.

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

qnikst ★★★★★
()
Ответ на: комментарий от jackill

И продолжил читать про Journal

Portable: journal files should be usable across the full range of Linux systems, regardless which CPU or endianess is used. Journal files generated on an embedded ARM system should be viewable on an x86 desktop, as if it had been generated locally.

А что, текстовые файлы больше не читаются?

Performance: journal operations for appending and browsing should be fast in terms of complexity. O(log n) or better is highly advisable, in order to provide for organization-wide log monitoring with good performance

Подозреваю, что это проблема для очень специфических сервисов. Могу еще сделать предположение, что ее уже решили.

Minimal Footprint: journal data files should be small in disk size, especially in the light that the amount of data generated might be substantially bigger than on classic syslog.

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

General Purpose Event Storage: the journal should be useful to store any kind of journal entry, regardless of its format, its meta data or size.

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

Base for Higher Level Tools: the journal should provide a generally useful API which can be used by health monitors, recovery tools, crash report generators and other higher level tools to access the logged journal data.

Писать туда температуру винта, проца, весь S.M.A.R.T и класть на диск. Они же резиновые, эти диски...

Logging is key when developing embedded devices, and also essential at the other end of the spectrum, for maintaining clusters. The journal needs to focus on generalizing the common use patterns while catering for the specific differences, and staying minimal in footprint

И вот со всем этим ...ом мы попытаемся залезть в телефоны и роутеры. Там системд прямо показан. Логгировать загрузку, выгрузку, температуру, пакеты сетевые - помимо всего прочего - и складывать все на SD.

Clustering & Network: Today computers seldom work in isolation. It is crucial that logging caters for that and journal files and utilities are from the ground on developed to support big multi-host installations.

Это будет новый мир - мир логов. Все ради логов.

Inspired by udev events, journal entries resemble environment blocks. A number of key/value fields, separated by line breaks, with uppercase variable names. In comparison to udev device events and real environment blocks there’s one major difference: while the focus is definitely on ASCII formatted strings, binary blobs as values are also supported — something which may be used to attach binary meta data such as ATA SMART health data, SCSI sense data, coredumps or firmware dumps.

Ну да, ASCII. Куда ж без него. Других-то данных в логах, не ASCII быть не может. Т.е. все, что не ASCII фигачим бинарниками. И coredump'ы туда же.

И пример отличный:

_SERVICE=systemd-logind.service
MESSAGE=User harald logged in
MESSAGE_ID=422bc3d271414bc8bc9570f222f24a9
_EXE=/lib/systemd/systemd-logind
_COMM=systemd-logind
_CMDLINE=/lib/systemd/systemd-logind
_PID=4711
_UID=0
_GID=0
_SYSTEMD_CGROUP=/system/systemd-logind.service
_CGROUPS=cpu:/system/systemd-logind.service
PRIORITY=6
_BOOT_ID=422bc3d271414bc8bc95870f222f24a9
_MACHINE_ID=c686f3b205dd48e0b43ceb6eda479721
_HOSTNAME=waldi
LOGIN_USER=500

Из этого мусора мы узнаем, что пользователь harald залогинился. Название машины (удивительно, правда?) waldi. И дальше на кой-то болт у нас название сервиса логина, его приоритет, в каких группах сервис состоит, какой UID у пользователя (та же нельзя выяснить). Не хватает времени логина, но это такая мелочь. Наверняка можно как-то извлечь из тысячи цифр, которые тут есть.

А могла бы быть одна строчка, легко обрабатываемая регэкспами...

Messages from unprivileged login users are split off into individual journal files, one per user. Using POSIX ACLs for controlling read access, it is ensured that users can access their own journal files. The journal entries generated by system services are by default not accessible by normal users, unless they are a member of a special Unix group. Note that the separation of files happens to accommodate for proper access control, but the global contexts of log entries is not lost, due to the client side coalescing of journal files, and by enforcing a single needle eye all messages are passed through to guarantee global ordering by automatically assigned sequence numbers. In effect this means that access control is guaranteed without compromise regarding the context of user journal entries.

Я так понимаю, что файлов все равно будет до черта, но доступ к ним будет прозрачный на основе ACL. Т.е. ко всему этому дерьму придется еще прикручивать политики selinux и не самые простые.

Later on we hope to hook up firmware messages (UEFI logs) and extend kernel based logging to support in-kernel structured logging. Since all fields are implicitly indexed in the journal data structure it is a relatively cheap operation to extract user data like from wtmp from the journal.

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

Потому как чем дальше, тем больше они понимали «ограниченность» текущей системы.

To make the monotonic timestamps useful all messages also carry the boot ID of the running Linux kernel (i.e. /proc/sys/kernel/random/boot_id).

Тоже правильно. Мало ли что. Предлагаю туда еще день рождения Линуса вкомпилить. И время в секундах от семидесятого года.

Rotation not only takes a maximum disk usage limit into account, but also monitors general disk usage levels in order to ensure that a certain amount of space is always kept free on disk.

А если не будет этого определенного пространства? Отключится или не даст писать?

Entries sent by clients are subject to implicit rate limiting, to avoid that rogue clients can flush relevant data out of the journal, by flooding it with is own data. The rate is adjusted by the amount of available disk space, so that higher message rates are allowed when disk space is generous and lower rates enforced when disk space is scarce

Да, так и есть - меньше места, меньше логи. Подумаешь, что-то пропустили. Все ради логов. Класс. Система решает за тебя.

jackill ★★★★★
()
Ответ на: комментарий от anonymous

Bro!!!! Ну, вот есть хоть один единомышленик!!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.