После четырёх месяцев разработки сформирован (https://lists.freedesktop.org/archives/systemd-devel/2017-Ma...) выпуск системного менеджера systemd 233 (http://www.freedesktop.org/software/systemd/). Из новшеств можно отметить перенос правил DBus из /etc в /usr, добавление генератора переменных окружения, задействование гибридного режима настройки cgroup, новые опции монтирования в fstab, поддержка автоматической настройки для монтирования разделов LUKS и Verity, возможность сохранения backtrace при записи core-дампов.
Основные изменения:
- Правила DBus теперь устанавливаются в иерархию /usr, а не в /etc. Для переопределения каталога следует использовать опцию "--with-dbuspolicydir=";- Все поставляемые в составе systemd скрипты на языке Python (в основном
то тестовые сценарии) теперь требуют для своей работы наличия Python 3;- В .network-файлы systemd-networkd добавлены новые параметры: В секцию "[DHCP]" добавлен параметр "ListenPort=", позволяющий явно указать UDP-порт для приёма запросов DHCP-клиентом. Добавлен параметр "Unmanaged=" для вывода интерфейсов из управления systemd-networkd. Добавлен параметр "IPv6ProxyNDPAddress=" для настройки адреса NDP Proxy для IPv6. Добавлены опции "ActiveSlave=" и "PrimarySlave=" для опрелеления приоритетов при агрегировании сетевых интерфейсов. В блоге "[Match]" обеспечена возможность задания исключений (логическое "нет");
- В /etc/fstab добавлены новые опции монтирования, специфичные для systemd: x-systemd.mount-timeout для ограничения максимального времени выполнения команды монтирования; x-systemd.device-bound для создания директории для монтирования при появлении устройства (при отключении устройства, точка монтирования будет удалена);
x-systemd.after и x-systemd.before для явного задания порядка монтирования (можно определить за или перед каким unit-ом или точкой монтирования следует выполнить монтирование текущего раздела);- В таймерах (.timer unit) добавлена возможность указания времени относительно конца месяца через использование разделителя "~" вместо "-" между днём и месяцем. Например, "*-02~03" приведёт к срабатыванию таймера за три дня до конца февраля. Также добавлен альтернативный синтаксис определения повторяющихся событий, например, "9..17/2:00" - запускать каждые два часа с 9 до 17 часов;
- Режим настройки cgroup теперь может выбираться на этапе загрузки через передачу ядру параметров "systemd.unified_cgroup_hierarchy=" и "systemd.legacy_systemd_cgroup_controller=", а также при компиляции через опцию "--with-default-hierarchy=". По умолчанию выставляется гибридный режим (устанавливается значение "hybrid"), но в будущем ожидается переход на унифицированную иерархию cgroups-v2 (groups-v2, значение "unified"). Для включения классического режима (cgroups-v1) следует использовать значение "legacy". Дистрибутивам рекомендовано начиная с systemd 233 выставлять режим "hybrid" для релизов, "unified" для экспериментальных сборок (например, для Fedora rawhide) и "legacy" для достижения наилучшей совместимости и стабильности;
- Гибридный режим настройки cgroup (смесь cgroups-v2 и cgroups-v1) модифицирован для улучшения совместимости с классическими конфигурациями cgroups-v1. Состав /sys/fs/cgroup приближен к классической иерархии cgroups-v1, включая наличие /sys/fs/cgroup/systemd. Из ограничений гибридного режима по сравнению с унифицированной иерархией
отмечается невозможность миграции процессов между двумя отделёнными поддеревьями cgroup для непривилегированных экземпляров systemd, запущенных в режиме "--user", даже если оба поддерева принадлежат одному пользователю (например, "systemd-run --user --scope" не будет работать при вызове вне текущего контекста "systemd --user");- В systemd-nspawn добавлена возможность автоматической настройки шифрованных разделов LUKS и верифицированных разделов Verity - когда контейнер загружается с шифрованного раздела будет запрошен пароль доступа, а когда с раздела Verity будет осуществлён поиск файла ".roothash" с проверочным хэшем;
- В systemd-fstab-generator добавлена проверка загрузки ядра с параметром "systemd.volatile=", что позволяет реализовать для обычных загрузок аналог режима
"--volatile" в systemd-nspawn, позволяющем загрузить систему без предварительно подготовленных директорий /etc и /var, корневой раздел с этими директориями будет создан на лету в tmpfs, а из системных разделов примонтирован только /usr (если указать "systemd.volatile=state", то будет использован обычный корневой раздел, а в tmpfs будет примонтирован только /var);- В unit-файлы добавлена новая опция "RootImage=", похожая на "RootDirectory=", но монтирующая директорию из заданного образа вместо использования существующей директории;- В unit-файлы добавлена опция "MountAPIVFS=", осуществляющая монтирование /proc, /sys и /dev ("API VFS") для сервиса;- В coredumpctl добавлена опция "--reverse" для вывода списка core-дампов в обратном порядке и возможность показа дампов, созданный в определённое время (опции "--since=" и "--until="). В coredumpctl также обеспечен вывод дополнительной информации об обрезанных, недоступных и сохраняемых в данный момент core-дампах. В systemd-coredump добавлены средства для выполнения обратной трассировки (backtrace) для интерпретируемых языков, например, для скриптов на Python;
- Добавлена опциональная возможность запуска исполняемых файлов для генерации переменных окружения на стадии загрузки конфигурации, что может быть использовано для добавления переменных окружения для запускаемых сервисов. По умолчанию поставляется генератор переменных окружения, использующих значения их каталогов
/etc/environment.d и ~/.config/environment.d/;- Реализована возможность обособленного запуска unit-тестов, не требующая наличия исходных текстов systemd и сборочного окружения. Тесты устанавливаются в каталог /usr/lib/systemd/tests/ и запускаются командой 'make install-tests';
- Начиная с выпуска 233 для работы systemd в ядре Linux должны быть включены опции CONFIG_CRYPTO_USER_API_HASH, CONFIG_CRYPTO_HMAC и CONFIG_CRYPTO_SHA256;
- В unit-файлах прекращена поддержка спецификаторов "%c", "%r" и "%R";
- При вызове службы debug-shell.service в качестве командной оболочки по умолчанию теперь всегда используется /bin/sh. Для настройки другой оболочки, например, /sbin/sushell, можно использовать сборочную опцию "--with-debug-shell=";
- Изменён список вариантов действий, выводимых при необходимости подтверждения запуска команды:
(c)ontinue, proceed without asking anymore
(D)ump, show the state of the unit
(f)ail, don't execute the command and pretend it failed
(h)elp
(i)nfo, show a short summary of the unit
(j)obs, show jobs that are in progress
(s)kip, don't execute the command and pretend it succeeded
(y)es, execute the command
Вариант "n" (No) удалён, чтобы не вводить в заблуждение. Свою реализацию диалога можно можно настроить через параметр "systemd.confirm_spawn=";
- Для сервисов, которые не смогли корректно запуститься из-за сбоя, теперь всегда вызывается команда "ExecStopPost=" (раньше сервис оставался в состоянии "failed" без запуска команд остановки);- Добавлена реализация MulticastDNS, включаемая командой "MulticastDNS=yes";
- В systemd-analyze добавлена команда "syscall-filter", позволяющая увидеть, какие группы системных вызовов определены в настройках unit-файлов (SystemCallFilter);
- Добавлены новые группы системных вызовов: "@filesystem", охватывающая системные вызовы, связанные с работой файловых систем; "@reboot" для вызовов, связанных с перезагрузкой и завершением работы; "@swap" для системных вызовов по настройке раздела подкачки;- Добавлен новая опция unit-файлов "RestrictNamespaces=", предназначенная для ограничения доступа к различным типам пространствам имён, например, можно запр...
URL: https://lists.freedesktop.org/archives/systemd-devel/2017-Ma...
Новость: http://www.opennet.me/opennews/art.shtml?num=46123
Может кто-нибудь внятно объяснить зачем:
> перенос правил DBus из /etc в /usr
> Может кто-нибудь внятно объяснить зачем:
>> перенос правил DBus из /etc в /usrВидимо, https://www.freedesktop.org/software/systemd/man/systemd.uni... строят свой замок слоновой кости, чтоб всё чинно, рядками, как у бальших.
> В systemd-fstab-generator добавлена проверка загрузки ядра с параметром "systemd.volatile=", что позволяет реализовать для обычных загрузок аналог режима "--volatile" в systemd-nspawn, позволяющем загрузить систему без предварительно подготовленных директорий /etc и /var, корневой раздел с этими директориями будет создан на лету в tmpfs, а из системных разделов примонтирован только /usr;думаю это взаимосвязанно
Этой идее уже сто лет^W три года https://www.opennet.me/opennews/art.shtml?num=40132
сто три года? О_О
> а из системных разделов примонтирован только /usr;Так, стоп!
Так /usr можно на отдельном разделе?
https://freedesktop.org/wiki/Software/systemd/separate-usr-i.../
> Может кто-нибудь внятно объяснить зачем:
>> перенос правил DBus из /etc в /usrЭто такая схема размещения конфигов. Дефолтные (дистрибутивные) конфиги лежат в /usr. Если админ хочет что-то поменять, он копирует их в /etc и правит там. /etc имеет приоритет над /usr.
В принципе логично и удобно. Для тех программ, которые эту схему не используют, лично я стараюсь копировать дефолтный конфиг перед правкой, чтобы в случае чего быстро откатить обратно. А так достаточно удалить свой файл из /etc.
> Это такая схема размещения конфигов. Дефолтные (дистрибутивные) конфиги лежат в /usr. Если
> админ хочет что-то поменять, он копирует их в /etc и правит
> там. /etc имеет приоритет над /usr.C такой логикой нужно весь /etc в /usr засунуть.
Кейс: С очередным обновлением приходит апдейт конфигов в /usr, и получается что "админовская версия" (точнее её части, которые были модифицированы в апдейте) уже не актуальны. Как с этим предлагается работать?
Если всё в /etc, то пакетный менеджер обнаруживает, что файл был изменен админом, кладет новую версию конфига рядом, и выводит сообщение админу "смерджи, пожалуйста". А с вариантом "конфиги в /usr" как?
Дурной вопрос. Каждый правоверный обязан читать бложек своего пророка на предмет новых откровений.
Точно так же.
потому что в /usr должны лежать конфиги системы, написанные майнтейнерами и приезжающие из пакетов, а в /etc - локальные, написанные админом.
А когда я ищу действующий конфиг, я куда должен лезть? В место А, если нет Б, если нет С, если нет Д, если нет - бл*, я за---лся!
> я куда должен лезть?а куда ты его клал?
ни куда? тогда в /usr/
Вы что, единственный админ в ойкумене?
> Вы что, единственный админ в ойкумене?А вы что, не знакомы с системами, которые администрируете?
Тут такое дело, что на практике иногда действительно так и бывает. Иногда впервые заходишь на машину которую до тебя настраивали несколько поколений админов (и программистов!) разной степени вменяемости и компетентности.Да, в теории конечно "вы же должны всё изучить и знать!" но на практике:
* На это чаще всего просто нет времени.
* О существовании некоторых машин вы узнаёте только когда они ломаются, т.к. передача проекта была осуществлена на уровне "вот вам xls файл, в нём всё описано!"
> * На это чаще всего просто нет времени.
> * О существовании некоторых машин вы узнаёте только когда они ломаются, т.к.
> передача проекта была осуществлена на уровне "вот вам xls файл, в
> нём всё описано!"Ну, это скорее организационные проблемы. К тому же, в системах с systemd этого нет лишь потому что они покамест довольно молоды: подождём лет десять, и будут те же самые проблемы. Тут даже дело не в степени адекватности предыдущих поколений админов, сколько в адекватности разработчиков данного инструмента.
> в системах с systemd этого нетsystemd уже 6 лет и проблем нет. Вы предлагаете ждать 16 лет (6+10) чтобы понять что правильная архитектура привела к полному решению нагноившейся проблемы? Долго же до вас доходит...
>> в системах с systemd этого нет
> systemd уже 6 лет и проблем нет.Как же. В 2014-2015м systemd имел тенденцию падать в сегфолт при выполнении элементарных операций, но это ж не проблема, что это я в самом деле. Хотите пруфлинк дам? Надо всего лишь зайти в архив debian-russian. :)
рассматривать systemd из debian смешно, они там на десятки версий отстают. Когда это давно починили в апстрими, вы получите обновление в следующем релизе. В debian странно поступили пытаются поддерживать функциональность systemd, пытаешься начинать использоваться и тут выясняется что версия настолько древняя в которой бага или просто функционал на начальном уровне. В redhat хотябы зарезали такой функционал, чтобы даже не пытался настраивать и делал и как раньше
О, знакомая песня. :)
Тут получается одни не могут сделать стабильную ветку, другие вкорячили а поддерживать до конца не в силах.
Но разве вкорячивание не аргументировалось тем, что бедным мейнтейнерам станет проще все поддерживать?
Оба правы. :)
>systemd уже 6 лет и проблем нет.В Багдаде всё спокойно :)
Вот только ты забыл что тут у людей и опыт и интернет таки есть ...
Так что мир-дверь-мяч ты :)
В паппет, ёпрст.
> потому что в /usr должны лежать конфиги системы, написанные майнтейнерами и приезжающие из пакетов, а в /etc - локальные, написанные админом.Ага. Мой любимый с некоторых пор вопрос: что такое "конфиги" в этом контексте?
А то однажды разговаривали-разговаривали о конфигах, а потом выяснилось, что это не конфиги демонов, а их .unit-файлы.
А всё почему? Потому что дефолтные конфиги от мейнтейнеров (которые именно конфиги демонов), могут оказаться разными, в зависимости от ряда факторов.
>> потому что в /usr должны лежать конфиги системы, написанные майнтейнерами и приезжающие из пакетов, а в /etc - локальные, написанные админом.
> Ага. Мой любимый с некоторых пор вопрос: что такое "конфиги" в этом контексте?Угу. И гробовое молчание.
Конечно, ведь если ответить на этот вопрос, то встанет следующий:
Понятно, почему юниты, являющиеся конфигурационными файлами для systemd, лежат в /usr. Не понятно, почему там должны лежать правила dbus, которые являются конфигурацией, внезапно, dbus.
> Понятно, почему юниты, являющиеся конфигурационными файлами для systemd, лежат в /usr. Не понятно, почему там должны лежать правила dbus, которые являются конфигурацией, внезапно, dbus.Потому что эта схема логична, понятна и удобна для абсолютного большинства конфигов.
> Потому что эта схема логична, понятна и удобна для абсолютного большинства конфигов.конфиги стали обладать мышлением? 8-(
я уже опасаюсь systemd
Да, и интеллект systemd начал превосходить интеллект многих среднестатистических админчиков локалхостов, привыкших к vi и вороху дерьма в /etc/init.d
> Да, и интеллект systemd начал превосходить интеллект многих среднестатистических админчиков
> локалхостов, привыкших к vi и вороху дерьма в /etc/init.dсам-то каким парком рулишь?
судя по апломбу - два сервера в бухгалтерии и один прокси? :)))))))))
И все три виндоуз :)
> Ага. Мой любимый с некоторых пор вопрос: что такое "конфиги" в этом контексте?
> А то однажды разговаривали-разговаривали о конфигах, а потом выяснилось, что это не конфиги демонов, а их .unit-файлы.Юнит-файлы - частный случай файлов конфигурации (в данном случае - файлов конфигурации systemd).
Файлы конфигурации D-Bus - другой частный случай.
А схема etc over usr работает понятно и прозрачно в обоих случаях, и во многих других.
> А схема etc over usr работает понятно и прозрачно в обоих случаях, и во многих других.Между прочим, "работает понятно и прозрачно" - это тот вопрос, на который я потратил очень много времени, чтобы оно так и было. Но вот ответьте мне: а в чём собственно цимес?
Ну можете вы откатиться, потому что у вас в /usr файлы с дефолтами всегда остаются. Но зачем? Что, вы так много юнитов меняете? Если нет, то не проще ли сделать бэкап редактируемого юнита?
Ну можете вы строить диффы конфигурации systemd. А толку? Смотреть диффы имеет смысл только тому, кто дефолты хорошо знает. А дефолты systemd, судя по новостям, меняются каждую версию.
PS: по поводу "многих других" случаев я даже не стану спрашивать какие. Их наверняка тысячи, у них у всех однотипно составлены конфиги и разумеется не более одного дефолтного конфига от мейнтейнера.
> Если нет, то не проще ли сделать бэкап редактируемого юнита?Кстати, если backup продолбан, пакет всегда можно скачать ещё один раз из репозитария, и переустановить, восстановив конфиг maintainer'а. Или просто вытащить из .rpm/.deb с помощью mc или утилит командной строки.
> потому что в /usr должны лежать конфиги системы, написанные майнтейнерами и приезжающие
> из пакетов, а в /etc - локальные, написанные админом.C такой логикой нужно весь /etc в /usr засунуть.
Кейс: С очередным обновлением приходит апдейт конфигов в /usr, и получается что "локальная версия" (точнее её части, которые были модифицированы в апдейте) уже не актуальны. Как с этим предлагается работать?
Если всё в /etc, то пакетный менеджер обнаруживает, что файл был изменен админом, кладет новую версию конфига рядом, и выводит сообщение админу "смерджи, пожалуйста". А с вариантом "конфиги в /usr" как?
> Кейс: С очередным обновлением приходит апдейт конфигов в /usrТы им ещё раскрой большой секрет, пакет может предоставлять несколько дефолтных конфигов в зависимости от цели установки. За примерами тоже далеко ходить не надо: apt-get install postfix.
Ох, Kroz, знаешь, сколько таких разговоров у меня уже было? :)
Не парься, они не слушают.
> C такой логикой нужно весь /etc в /usr засунуть.Я подозреваю, что там один кадр забыл, что есть репозитарии, из которых всегда можно вытащить изначальный пакетный конфиг вместе с самим пакетом. Или вообще не догадывался об этом, т.к. пришёл с MS Windows.
>> C такой логикой нужно весь /etc в /usr засунуть.
> Я подозреваю, что там один кадр забыл, что есть репозитарии, из которых
> всегда можно вытащить изначальный пакетный конфиг вместе с самим пакетом. Или
> вообще не догадывался об этом, т.к. пришёл с MS Windows.Он что-то говорил на тему "давайте заменим пакетный менеджер на btrfs". Может быть ему понравились снапшоты btrfs? Зная Поттеринга, видение его могло бы быть примерно таким: systemd мониторит появление новых и изменения старых юнитов и каждый раз при обнаружении оных делает снапшот.
> потому что в /usr должны лежать конфиги системы, написанные майнтейнерами и приезжающие
> из пакетов, а в /etc - локальные, написанные админом.А зачем нужны конфиги системы, написанные "майнтейнерами", если есть сисадминские? Это я как maintainer спрашиваю.
> перенос правил DBus из /etc в /usrНадо чаще так делать. В следующем релизе нужно вернуть обратно.
>> перенос правил DBus из /etc в /usr
> Надо чаще так делать. В следующем релизе нужно вернуть обратно.В следующем будут "/usr merge" для снова образовавшийся /usr топтать. Эта музыка будет вечной!
А зачем замена fstab, cron, lxc, docker, networkmanager, chroot, rsyslog, resolv, udev, login и я заманался вычитывать что там ещё есть? Я был противником системд как раз из-за того что в него пихают всё подряд. Но действительно на многопоточных конфигурациях не хватало современной замены систем5. Если добавить ядро ОС и coreutils практически готовый дистрибутив.
> на многопоточных конфигурацияхКаких, простите?
Многопоточных - много потоков. Это, уважаемый динозавр, когда у компьютера потоков исполнения задач больше 1. Например технология HT от intel или больше одного ядра у процессора. Каждая задача выполняется в своём потоке и в зависимости от количества потоков, одновременно могут стартовать монтирование шар, настройка сети, внутренних систем.
>> Например технология HT от intelHT это просто хитро закрученный конвейер c блоком регистров вместо еще одного ядра.
>>Каждая задача выполняется в своём потоке
Неправильный ответ в отношении systemd, он просто хорошо оптимизирует запуск сервисов, учитывая их зависимости - копия scm от ms, который копия старта из netware.
>> HT это просто хитро закрученный конвейер c блоком регистров вместо еще одного ядра.Не совсем, всё сложнее. Процессор определяется как два и забирает себе инструкции двух разных потоков. Суть в том, что каждая инструкция разбивается на микрокоманды и формируется очередь микрокоманд для каждого потока. Так как две очереди по большей части не зависят друг от друга, то их микрокоманды могут идти на разные исполнительные блоки процессора и обрабатываться параллельно.
Мало того, конвейер угадывает будущее, т.е. обрабатывает микрокоманды наперёд, максимально задействуя все вычислительные блоки, какие возможно.
Всё это вместе взятое позволяет на порядок повысить производительность, не прибегая к повышению частоты процессора.
Вы бы все хоть писали в одной терминологии.Ваш "поток" - это английское "thread" - термин, используемый при переводе документации для программирования в среде Windows (!). В среде Линукс термин "thread" переводят как "нити". Но это всё в прикладном (!) программировании.
Когда речь заходит о процессорах, используется терминология Интел. Никаких "потоков" и "микрокоманд" там нет.
Процессор вообще ничего не знает о "потоках".
> конвейер угадывает будущее
Не угадывает, а предсказывает. И не будущее, а переходы.
В Intel Pentium он предполагал, что в условии если-то (истина-ложь) наиболее вероятен тот переход, который произошёл в прошлый раз. Начиная с Intel Pentium 2 для предсказания используются 3 последних перехода, предполагая что переход будет туда, куда произошли два из трёх.
> не прибегая к повышению частоты процессора
Это вообще отдельная тема, в которой ты явно не шаришь.
> позволяет на порядок повысить производительность
Весьма спорно. HT даёт процентов 10-20% в ненагруженных задачах и замедляет (!) выполнение при нагрузке свыше 60% (угадай почему).
И нужен он для другого, а конкретно - писькометрии количеством ядер (маркетинг, десу) и сглаживаем просадок если в ОС не смогли реализовать нормальный балансировщик нагрузки (Линукс, десу).
>> "микрокоманд" там нет.Да ну? Я системный разработчик и интересуюсь оптимизацией под процессоры, соответственно. Ваше заявление относится к процессорам 10-летней давности. На всё ваше сообщение я могу посоветовать Вам почитать хотя бы Архитектуру ЭВМ Таненбаума. Ну или пошерстить по статьям Википедии, если книга напугает размером.
И ещё, после того, как изучите вопрос, ответьте на вопрос: какая в этом десятилетии была самая главная задача разработчиков процессоров? Если правильно ответите на вопрос, считайте, что вы уже в теме. Могу подсказать ответ, - он связан с исполнением микрокоманд (или микроинструкций, как вам угодно), которых "там нет" .
>Я системный разработчик и интересуюсь оптимизацией под процессоры,Да нет, ты - очередная "дочь морского офицера", у которой "тут всё не так однозначно" :)
Иди к лужам и береди им душу :-)
Не для писькометрии и не из-за балансировщика он нужен. Он нужен, чтобы увеличить загрузку существующих исполнительных блоков, и не делать ради большего параллелизма ещё одно честное ядро.А почему честное ядро не хотят делать - знаете? Нет, не стоимость.
Не томи!!!
Приятно видеть, что здесь есть люди с которыми можно что-либо пообсуждать. Мне теперь и самому интересно, почему больше ядер не делают. Сам я над этим не задумывался никогда. Думаете, для удержания энергопотребления на низком уровне?
Внезапно, "монтирование шар, настройка сети, внутренних систем" выполняется практически с той же скоростью вне зависимости от количества потоков, исполняемых вашим CPU одновременно.
/etc/fstab как был, так и остался
cron с этим "crontab -e" - все правильно сделали
lxc - более низкий уровень, используется в systemd
docker - появился на 3 года позже systemd, имеет проблемы с безопасностью, другое предназначение
networkmanager - кусок крапа, все правильно сделали
и т.д.
Если бы не пихали всё в одно - слова бы никто не говорил.> cron с этим "crontab -e" - все правильно сделали
Меня всё устраивает.
> networkmanager - кусок крапа, все правильно сделали
Что это такое вообще и почему это должно быть у меня в системе? Точнее почему оно отсутствует?
>> cron с этим "crontab -e" - все правильно сделали
> Меня всё устраивает.Это ваши личные проблемы. А вот мейнтейнеры дебиана, например, задолбались писать костыли типа
> # By default, run at 00:57 on every Sunday, but do nothing unless the day of
> # the month is less than or equal to 7. Thus, only run on the first Sunday of
> # each month. crontab(5) sucks, unfortunately, in this regard; therefore this
> # hack (see #380425).
> 57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi
>>> cron с этим "crontab -e" - все правильно сделали
>> Меня всё устраивает.
> Это ваши личные проблемы. А вот мейнтейнеры дебиана, например, задолбались писать костыли
> типа
>> # By default, run at 00:57 on every Sunday, but do nothing unless the day of
>> # the month is less than or equal to 7. Thus, only run on the first Sunday of
>> # each month. crontab(5) sucks, unfortunately, in this regard; therefore this
>> # hack (see #380425).
>> 57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fiНеа. Это не проблемы, а достоинства cron-а.
Если что-то не предусмотрено в systemd - "у вас не должно быть такой задачи", "мы такое не поддерживаем", "уходите, не вешайте нам больше таких багов". Ах да, и "get off ma lawn".
Если что-то не предусмотрено в crontab - "ребята, напишите shell скрипт, с парой дополнительных проверок, и всё будет зашибись".
> Начиная с выпуска 233 для работы systemd в ядре Linux должны быть включены опции CONFIG_CRYPTO_USER_API_HASH, CONFIG_CRYPTO_HMAC и CONFIG_CRYPTO_SHA256;А говорят приложение не может требовать опций ядра..
А еще приложений можно сразу много запустить, и они хранят документы в $HOME. А тут какие то /usr и /etс... Что за мерзость, действительно - опции ядра, системные файлы. Даешь только кнопку "Сделать зае__сь", и не надо никаких системд.
> Даешь только кнопку "Сделать зае__сь"Прекрасное описание работы systemd. Зачем думать? Там же все юниты за тебя всё делают, настраивают, запускают сервисы.
>> Начиная с выпуска 233 для работы systemd в ядре Linux должны быть включены опции CONFIG_CRYPTO_USER_API_HASH, CONFIG_CRYPTO_HMAC и CONFIG_CRYPTO_SHA256;
> А говорят приложение не может требовать опций ядра..Этот комбайн ещё не того потребует скоро. Они форкнут ядро и включат всё в него. А потом оно так разрастётся, что останется один бинарь, который умеет ВСЁ.
>> Начиная с выпуска 233 для работы systemd в ядре Linux должны быть включены опции CONFIG_CRYPTO_USER_API_HASH, CONFIG_CRYPTO_HMAC и CONFIG_CRYPTO_SHA256;
> А говорят приложение не может требовать опций ядра..Скажите это разработчикам LXC, Docker, iptables, DRBD, ipvs, brctl, tgtd, mdadm и десятков других программ, а то они как-то не в курсе :)
админ локал хоста из вижу пока из пользы что комп мнгновенно выключается
пока одобряю но не понятно как в логах копатся куда они делись, документация портянка лучше стар трек посмотреть
Зачем вам линукс если вы не можете забить в гугл systemd logging?
> Зачем вам линукс если вы не можете забить в гугл systemd logging?Зачем мне гуглить, если без systemd у меня все логи в /var/log?
А с сюстемде они у вас в оперативке по умолчанию, после ребута journalctl всегда девственник. Так то.
Для локалхоста и мелких серверов всё-же проще в текстовики, ротацию только всему по умолчанию навязать :)
> Для локалхоста и мелких серверов всё-же проще в текстовики, ротацию только всему по умолчанию навязать :)Это в каком-таком дистрибутиве на /var/log не натравлен ротатор по умолчанию? :)
> Это в каком-таком дистрибутиве на /var/log не натравлен ротатор по умолчанию? :)Ставишь Debian. И не ставишь logrotate. Учись, студент! :D
>> Это в каком-таком дистрибутиве на /var/log не натравлен ротатор по умолчанию? :)
> Ставишь Debian. И не ставишь logrotate. Учись, студент! :DPackage: logrotate
Priority: importanthttps://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics....
> *Important* packages should be found on any Unix-like system.
> Other packages which the system will not run well or be usable without will be here.Короче, это ж ещё додуматься надо! :)
И по-любому он вместе с minimal-install ставится, ибо я всегда ставлюсь через debootstrap, и никогда отдельно logrotate не ставил - сам прилетал.
> Для локалхоста и мелких серверов всё-же проще в текстовикиПочему? Как по мне, так даже на локалхосте journalctl с фишками типа -b-1, --since и --until гораздо удобнее костылей на грепе.
Дуууу ... а шаг в сторону и тебе стреляют в голову! Иди в >|< - если мне нужна будет огороженность - винда и так уже существует.
когда уже Поттеринг свое ядро запилит
> когда уже Поттеринг свое ядро запилит"Мы" уж скорее hurd до десктопа допилим.
Фришники точно GNU&GPL из базы быстрее выкинут.
А потом, кому юникс-шел сложен, слаб для писания ядра, нет?А редхату https://www.dwheeler.com/essays/linux-kernel-cost.html#results слабО "своё" ядро "поднять". Денег у них столько нет. (Столько денег даже у мс нет.) Рх только опенсорсные поделки монетизируют. И безобразничает и мелко пакостит с init-pid1-ами/udev-ами и прочими "free"desktop-ами, партнёрит с ораклами и майкрософтами и прочими мпеглами. Вал по плану и пр.СУБЖ.
А что сейчас происходит с SysVinit и какие перспективы?
> А что сейчас происходит с SysVinit и какие перспективы?Он просто работает. Причем и на машинах с субжом. Прикинь, да??
Про переспективы -- спроси в профильной новости об его новом%-S релизе.
И systemd тоже просто работает. Никаких причин менять одно на другое нет.Но у systemd есть перспективы, а у sysvinit если они и есть, то о них знают только очень информированные и глубоко законспирированные члены форума.
> И systemd тоже просто работает.Враньёёооо....
>Никаких причин менять одно на другое нет.
Есть! И это та же причина, по которой Рх его всем вкорячивают.
> Но у systemd есть перспективы, а у sysvinit если они и есть,
Враньёёооо.
> то о них знают только очень информированные и глубоко законспирированные члены
> форума.Враньёо.
Нельзя ли аргументированно? Похож на бабку в церкви.
> Нельзя ли аргументированно? Похож на бабку в церкви.Ну так sysvinit - это духовная скрепа юникса! В нее надо просто верить, все эти дискуссии и аргументации - от лукавого.
> И systemd тоже просто работает. Никаких причин менять одно на другое нет.У systemd только одна перспектива: его проталкивает "Красная Шапочка".
А по поводу того, что оно "просто работает", так это враньёёёёооо:
https://www.opennet.me/base/sys/systemd_myth.txt.html
По ссылке явно про старую версию. В новой же всё не так. И когда вы напишите про новую, то уже к тому времени выпустят следующую и всё опять изменится. systemd унаследовал критическую неуязвимость от своего создателя.
> По ссылке явно про старую версию.Единственное, во что я поверю, так это в то, что Вы прочитали дату публикации исходной статьи, которая состоялась в 2014м году. Сам текст Вы даже взглядом не удостоили.
Там, понимаете ли, про дизайн и общий подход. К конкретной версии не привязано.
> Там, понимаете ли, про дизайн и общий подход. К конкретной версии не привязано.И что характерно, ни одного технического аргумента. Сплошное "я художник, я так вижу".
> И что характерно, ни одного технического аргумента.Опять не читал. Анонимы такие анонимы. :)
> И что характерно, ни одного технического аргумента. Сплошное "я художник, я так
> вижу".В код системды хоть раз смотрел?
strcpy(mempcpy(mempcpy(r, f, a + 1), i, b), e);
...
arg_header = strdup(option+7);
...
strcpy(mempcpy(mempcpy(r, f, a + 1), i, b), e);
...
ret = new(char, (e - slice) + 1 + strlen(name) + 6 + 1);
Когда веруешь, аргумент не нужны.
> Когда веруешь, аргумент не нужны.Согласен. Они аргументацию не воспринимают, даже если им её ужё разжёванную до мелочей прямо в рот запихать. Список тот появился не просто так, а потому, что один раз прописал, и можно оставлять ссылочку, не утруждая себя по-новой строчить одно и то же.
Флеймы эти пошли массово году эдак в 2014м, и где-то спустя год всем опостылели в конец, потому что каждый раз одно и то же: ты объясняешь-объясняешь, что и как, но что бы ни было сказано в конце ланнартский фанат заявляет, что не было технической аргументации, что оппонент ретроград и закрыт для нового... Ну в общем, заявляет, что все Дартаньяны, а он - ...
Вот тогда была найдена статья и сделана калька. Но напрасно. Они и её не читают тоже. :)
А ты сам её читал?В доказательстве 1.1 он опровергает утверждение "компоненты Systemd имеют хорошо описанные
интерфейсы" утверждением "интерфейсы нестабильны". Это не опровержение!В доказательстве 1.2 он говорит что должно/не должно systemd на основании того, чем является/не является ядро. Это доказательство из серии "в огороде бузина, в Киеве дядька."
Доказательство 4.1: он признаёт, что файлы скриптов systemd проще, чем для sysvinit, соглашаясь с исходным утверждением. Затем начинает сравнивать сложность программного кода systemd и sysvinit (не видя самого кода) и, на основании того, что скрипты проще, делает вывод что systemd сложнее.
Ты приводишь это как доказательство, означает ли это, что ты с этим согласен?
Отдельный камень в сторону перевода. Переводчик бестолковый и сам это признаёт.
"binary file" = бинарник
"Socket activation" = сокетная активация
"Post" = пост
Что это за бестолочь? Чтобы переводить нужно владеть родным языком лучше, чем иностранным. А чтобы переводить техническую литературу нужно знать технический английский. Очевидно, что переводчик им не владеет.
> В доказательстве 1.1 он опровергает утверждение "компоненты Systemd имеют хорошо описанные
> интерфейсы" утверждением "интерфейсы нестабильны". Это не опровержение!
>> #1.1 "Компоненты Systemd имеют хорошо описанные интерфейсы, и поэтому вы можете просто заменить части, которые вам не нравятся"Суть-то Вы уловили, только аргумент против несколько другого утверждения.
> В доказательстве 1.2 он говорит что должно/не должно systemd на основании того,
> чем является/не является ядро. Это доказательство из серии "в огороде бузина,
> в Киеве дядька.""Следует ли systemd быть монолитным или нет - абсолютно никак не относится к ядру Linux".
Я было подумал, что Вы читаете между строк, но вдруг понял, что строка-то всего одна...> Доказательство 4.1: он признаёт, что файлы скриптов systemd проще,
> чем для sysvinit, соглашаясь с исходным утверждением.Вранёёооо:
>> #4.1: "Unit-файлы уменьшают сложность"
>>
>> Хотя unit-файлы действительно выглядят проще init-скриптов и могут
>> уменьшить сложность определяемых сервисов, они ни уменьшают сложность
>> системы инициализации, ни уменьшают сложность поиска ошибок в системе
>> инициализации, когда она ведёт себя не правильноНифига себе "соглашается с исходным утверждением", а? :)
> Затем начинает сравнивать сложность программного кода systemd и
> sysvinit (не видя самого кода) и, на основании того, что скрипты
> проще, делает вывод что systemd сложнее.Ну офигеть. То есть если sysvinit проще systemd, из этого не следует, что systemd сложнее sysvinit?
Вопрос: действительно ли unit-файлы проще init-скриптов?Ответ: unit-файлы действительно проще init-скриптов
Абсолютное, полное согласие.
> Нифига себе "соглашается с исходным утверждением", а? :)
А вот после этого Остапа понесло и он начал сравнивать исходный код systemd, написанный на Си, с shell-скриптами. В следующих двух вопросах он подробно расписывает почему поиск ошибок и отладка программ на Си сложнее, чем написание shell-скрипта.
> То есть если sysvinit проще systemd, из этого не следует, что systemd сложнее sysvinit
Если скрипт для sysvinit проще исходного кода systemd, из этого совсем не следует, что systemd сложнее sysvinit. Я думал, вы это понимаете и без моих объяснений...
Q 1.1: Компоненты Systemd имеют хорошо описанные
интерфейсы, и поэтому вы можете просто заменить части, которые вам не
нравятсяA: Это рассуждение ошибочно из-за одного упущения. Не все его интерфейсы
стабильныСтоп игра! Речь в вопросе шла о документированности, а не о стабильности. Ответ не по теме вопроса.
Q 1.2: Ядро Linux монолитное, поэтому это нормально, что
systemd монолитен.A: Следует ли systemd быть монолитным или
нет - абсолютно никак не относится к ядру Linux.Вопрос был в том насколько нормально что systemd монолитен, ответ - это никак не относится к ядру. Да, не относится, но где ответ на вопрос?
Q 2: Многие используют systemd, значит ты тоже должен
A: Классический пример ошибки "большинство не может ошибаться".
Ошибаться в чём? Из того, что systemd использует большинство следует лишь то, что для большинства он более удобен, чем что-то другое, а значит он с большой вероятностью (пропорциональной доле systemd на рынке) будет самым удобным решением и для вас.
Q 2.1, 3 -- болтология
Q 4: Unit-файлы лучше, чем shell-скрипты
A: Это ошибочное обобщение (почему?). Чем меньше кода - тем лучше (общеизвестная истина), но есть важные детали (детали есть всегда; какие именно?), на которые часто смотрят сквозь пальцы.
Обвинить в неведении, но не сказать в чём оно заключается. Затем "заболтать" тему.
Q 4.1: Unit-файлы уменьшают сложность
Расписал выше
Дальше продолжать? Покажи где он ответил по теме, внятно и содержательно?
В моём предыдущем коменте уровнем выше был только сарказм и ничего более :-) Статью естесственно прочитал целиком, очень познавательно, спасибо!
PS: Я просто попытался изобразить текст так как бы его написали поклонники поттеринга. Видимо получилось :) А сам я давно devuan юзаю, на локалхосте и на серверах
та статья — это рационализация точки зрения "системд плохой".
Я с некоторыми пунктами согласен. Но в целом со статьей — не до конца.Например, аргумент о сложности. Дескать, системд 250,000 строк на си, а все скрипты в дебиане — 10,000 строк.
Но
1) Баш гораздо более высокоуровневый — 10,000 на баше потребуют гораздо больше на си
2) почему бы к 10,000 не добавить количество строк си в исходных кодах баша?
> та статья — это рационализация точки зрения "системд плохой".
> Я с некоторыми пунктами согласен. Но в целом со статьей — не
> до конца.
> Например, аргумент о сложности. Дескать, системд 250,000 строк на си, а все
> скрипты в дебиане — 10,000 строк.
> Но
> 1) Баш гораздо более высокоуровневый — 10,000 на баше потребуют гораздо больше
> на сиДети! Сегодня мы будем играть в Угадайку!! А угадайте, кто с кем соревнуется, кто кого обгоняет и назовите имена участникао по... числу строк кода на Си в проектах:
| | Lang. | Code | Comment | Comm.% | Blank | Total | Lang. % |
| #1 | C | 107,704 | 22,942 | 17.6% | 22,910 | 153,556 | 64.1% |
| #2 | C | 122,257 | 5,332 | 4.2% | 44,335 | 171,924 | 71.8% |
| #3 | C | 270,920 | 31,560 | 10.4% | 84,998 | 387,478 | 82.8% |
| #4 | C | 330,154 | 84,492 | 20.4% | 65,991 | 480,637 | 22.4% |
| #5 | C | 511,630 | 150,702 | 22.8% | 94,358 | 756,690 | 32.5% |
> 2) почему бы к 10,000 не добавить количество строк си в исходных
> кодах баша?Да! Престо, какой из коннурсантов ##1--5 выше -- bash, а какой == твой разжиревший фетиш.
Или б*****о.
Дядя, а без кривляний умеете?
> Дядя, а без кривляний умеете?Бала-бол.
О нет! Дядя, видимо, mentally challenged.Высказывать свою точку зрения, приводя аргументы, не умеет. Вопросы читать не умеет.
Серьезно, сложно сказать "я считаю, ты не прав, потому что баш это 100к, а системд, скажем — 500"? Даже текста надо меньше.
Я бы, конечно, ответил, что в системд ты посчитал logind, udev, localectl, journalctl, и уж если считать, то надо добавлять к башу аналоги.
А более того, порядок величин тот же. Разница между 100к и 200к не такая уж большая
>[оверквотинг удален]
>> Я с некоторыми пунктами согласен. Но в целом со статьей — не
>> до конца.
>> Например, аргумент о сложности. Дескать, системд 250,000 строк на си, а все
>> скрипты в дебиане — 10,000 строк.
>> Но
>> 1) Баш гораздо более высокоуровневый — 10,000 на баше потребуют гораздо больше
>> на си
> Дети! Сегодня мы будем играть в Угадайку!! А угадайте, кто с кем
> соревнуется, кто кого обгоняет и назовите имена участникао по... числу строк
> кода на Си в проектах:Ответы
+ На "5 с плюсом": http://www.opennet.me/openforum/vsluhforumID3/107695.html#47| | Total C | C Code | Си, % | Comment | Cmt.% | Blank | Bl.% |
| GNU Bash | 158,949 | 111,837 | 64.7% | 23,584 | 17.4% | 23,528 | 21% |
| Nginx | 178,751 | 127,242 | 71.7% | 5,407 | 4.1% | 46,102 | 36.2% |
| Systemd | 418,943 | 293,497 | 82.7% | 33,916 | 10.4% | 91,530 | 31.1% |
| GNU Emacs | 484,528 | 332,432 | 22.7% | 85,545 | 20.5% | 66,551 | 20% |
| Apache HTTPD | 767,236 | 519,865 | 32.5% | 151,975 | 22.6% | 95,396 | 18.3% |(убрал Lang, добавил Bl.%, переместил Total "вперёд"; переименовал Total => Total-C; обновил чёрноутковскими _сегодняшнимим_ данными.)
+ "Коммерсы"/индустриальные программёры (№№2,3) налегают на пустые строки и недовкладывают комментариев по ср.с "пр." конкурсантами. Совпадение, наверное, выборка мала.
>> 2) почему бы к 10,000 не добавить количество строк си в исходных
>> кодах баша?
> Да! Престо, какой
> твой разжиревший фетиш.
>б*****Л.
> Я с некоторыми пунктами согласен. Но в целом со статьей — не до конца.
> Например, аргумент о сложности. Дескать, системд 250,000 строк на си, а все скрипты в дебиане — 10,000 строк.Именно. Даже если взять sysvinit и посчитать вместе со скриптами запуска, разница получается аж на порядок.
> 1) Баш гораздо более высокоуровневый — 10,000 на баше потребуют гораздо больше на си
> 2) почему бы к 10,000 не добавить количество строк си в исходных кодах баша?А почему бы Вам тогда не прибавить к systemd количество строк в исходниках gcc?
Давайте тогда ещё вспомним, что sysvinit позволяет писать не только на bash, но вообще на любых скриптовых языках - давайте и количество строк кода в их интерпретаторах посчитаем?
И скрипты на bash (вот ведь неожиданность) дёргают самые разные утилиты, может нам и их посчитать?Добавлять удобно - чем больше добавляем, тем меньше относительная разница между проектами. А почему бы не поступить наоборот? Давайте Вы вычтете содержимое unit-файлов, а мы - код shell-скриптов. Не будет ли это сравнение более честным? Но тогда разница будет далеко не на один порядок, вот в чём беда.
Суть же сравнения в том, что количество строк в проекте - это количество мест, где можно совершить ошибку. И чем меньше строк - тем меньше ошибок. Для того DSL и существуют: чтобы уменьшать их количество.
Ты в курсе, что сложную задачу делят на части, каждую из которых решают разные люди?Программисты пишут систему инициализации (СИ), администраторы пишут скрипты для СИ.
Ты пытаешься складывать-вычитать количество строк исходного кода СИ с количеством строк в скриптах - какой в этом смысл?
Суммарная сложность системы остаётся постоянной, но мы можем изменять сложность отдельных частей. В systemd посчитали, что нужно уменьшить сложность скриптов, увеличив сложность СИ. И то, что systemd стал популярным означает, что это решение было верным.
> Ты пытаешься складывать-вычитать количество строк исходного кода СИ с количеством строк
> в скриптах - какой в этом смысл?Смысл - в последнем абзаце.
"количество строк в проекте - это количество мест, где можно совершить ошибку. И чем меньше строк - тем меньше ошибок"
Что ж, никто не мешает создать ещё одну систему инициализации, нацеленную на уменьшение суммарного количества строк в исходном коде и скриптах.У меня есть сомнения, что эта идея станет популярной, но кто знает...
> чем меньше строк - тем меньше ошибокНет.
Чем меньше строк, тем меньше мест где можно допустить ошибку, но это не означает что они были допущены и не были исправлены.
Посмотри на мишку Вонни, он в каждом слове по несколько ошибок делает. А Лев Толстой написал толстенную книжку и почти не накосячил.
> Посмотри на мишку Вонни, он в каждом слове по несколько ошибок делает.
> А Лев Толстой написал толстенную книжку и почти не накосячил.проблемы начались, когда мишки Вонни на "Войну и мир" замахнулся
Баш я прибавил, т.к. скрипты пишутся на баше. Я апеллирую к утверждению «системд имеет много строк кода на си. Чем больше строк кода в процессе инициализации, тем он сложнее и ненадежнее».Но в случае с sysvinit, bash является частью системы инициализации. Потому надо брать исходники sysvinit, исходники bash и сравнивать их.
Потом, systemd имеет продвинутую систему журналирования (весьма неплохую, кстати. Я люблю плейтекст, но переход на бинарный формат для увеличения производительности записи и поиска — это правильный шаг). Т.е. сравнение уже неравное получается.
Я хочу прояснить: с теплотой вспоминаю времена, когда стартовал демоны, добавляя их в deamons array в rc.conf.
Но это решение для одной машины. И потом и хорошо помню, как для ускорения процесса загрузки предлагалось _экспериментировать_ с запуском в бекграунде. Т.е. процесс не автоматизируемый.
Системд в этом смысле — это гораздо больше, чем система инициализации. Это инициатива, призванная навести порядок в запускаемых демонах, ведь необходимо явно задекларировать зависимости и т.д..
Это как сравнивать make install с apt-get install. make install проще дебажить, кол-во строк кода на си меньше, можно сделать все, что угодно, система гибкая, простая, каждая бабушка понимает...
А с этим apt я не могу легко установить свою программу на любую систему, приходится возиться с dpkg, читать плохую документацию и т.д..
> Баш я прибавил, т.к. скрипты пишутся на баше. Я апеллирую к утверждению
> «системд имеет много строк кода на си. Чем больше строк кода
> в процессе инициализации, тем он сложнее и ненадежнее».
>
> Но в случае с sysvinit, bash является частью системы инициализации. Потому надо
> брать исходники sysvinit, исходники bash и сравнивать их.Вообще-то bash частью sysvinit не является. То, что после запуска init запускает скрипт, который производит дальнейшую инициализацию ОС - не делает этот скрипт частью init-а. Если включать в подсчёт сам скрипт, то есть нюанс: в разных осях sysvinit запускает разные скрипты. Где-то они на shell, где-то на python. Из shell-ов это может быть bash, может быть dash, может быть что-либо ещё. Почему же именно bash?
А знаете что ещё? Вместо скриптов для запуска в /etc/init.d могут быть бинари. На протяжении десятков лет можно было использовать бинари вместо скриптов. Главное, чтобы они принимали аргументы start, stop, restart, reload... Что ж нам теперь, gcc в подсчёт включать?
И вот при этом Вы предлагаете включить в подсчёт строк кода не только скрипты, но и один из интерпретаторов? У меня только один вопрос остаётся тогда, который я уже задал: почему Вы не хотите присовокупить сюда ещё код всех бинарных утилит, которые дёргаются этими скриптами?
--
Ну хорошо. Не смотря на то, что bash не является частью sysvinit, давайте сложим. Вот тут рядом пост Митрофанова, по которому получается, что даже если мы сложим, всё равно systemd в проигрыше. Правда, уже не на порядок, конечо. Если Вам с этого легче - да ради бога.
Может быть теперь это для Вас "незначительная разница", но имейте в виду, что эти 100к строчек отлаживали последние 30 лет или около того. Ваша systemd существует в 5 раз меньше, а весит в 3 раза больше.
> Потом, systemd имеет продвинутую систему журналирования (весьма неплохую, кстати. Я люблю
> плейтекст, но переход на бинарный формат для увеличения производительности записи и
> поиска — это правильный шаг). Т.е. сравнение уже неравное получается.Нет, не правильный.
Раз. (см. #10 - про бинарные логи) https://www.opennet.me/base/sys/systemd_myth.txt.html
Два. (укороченный до сути вариант предудущего) https://www.opennet.me/openforum/vsluhforumID3/110582.html#161> Я хочу прояснить: с теплотой вспоминаю времена, когда стартовал демоны, добавляя их
> в deamons array в rc.conf.
> Но это решение для одной машины. И потом и хорошо помню, как для
> ускорения процесса загрузки предлагалось _экспериментировать_ с
> запуском в бекграунде. Т.е. процесс не автоматизируемый.Да, я тоже с теплотой их вспоминаю, но ведь современный sysvinit уже давным-давно не такой.
> Системд в этом смысле — это гораздо больше, чем система
> инициализации. Это инициатива, призванная навести порядок в
> запускаемых демонах, ведь необходимо явно задекларировать
> зависимости и т.д..Так ведь в том и дело, что эта инициатива в дебиановском sysvinit уже имелась на момент создания systemd. Ко скриптам инициализации были добавлены LSB-заголовки, в которых прописали зависимости. Sysvinit стартовал демоны параллельно и разруливал зависимости.
https://wiki.debian.org/LSBInitScripts
Обратите внимание: они были добавлены ещё в Lenny. А это, извините, 2009й. То есть за два года до появления Systemd.
> Это как сравнивать make install с apt-get install. make install проще дебажить,
> кол-во строк кода на си меньше, можно сделать все, что угодно,
> система гибкая, простая, каждая бабушка понимает...
> А с этим apt я не могу легко установить свою программу на
> любую систему, приходится возиться с dpkg, читать плохую документацию и т.д..Сравнение хорошее, за той лишь разницей, что APT решает реальную проблему: он разруливает процесс доставки и установки огромного количества пакетов. Make же этим не занимается.
А вот systemd не решает никаких старых проблем, зато привносит море новых. Хотите пруфов, хотите? Их у меня много. Вся рассылка debian-russian, а ещё располагаю подборкой комментариев с opennet.
> Почему же именно bash?цепочки инита
kernel -> (sysvinit -> bash + grep + ps + kill + ...) -> target binary
kernel -> systemd -> target binaryВ первом случае может быть другой шел, да. Но не суть. Мне не понравился сам лишь подход, что в случае с sysvinit считаем строчки "юнит-файлов" (они же скрипты), а в случае с systemd — строчки системы инициализации.
> эти 100к строчек отлаживали последние 30 лет или около того
С таким подходом никогда нельзя разрабатывать что-то новое. Говорить, что системд плохая, потому что ее конкурент уже 30 лет работает — это, мне кажется, неконструктивно. Конструктивно говорить, что в системд есть баги (и это правда), говорить какие именно, и тогда их будут фиксить.
> Раз. (см. #10 - про бинарные логи)
все зависит от реализации. Современные информационные системы уже давно обходят проблему фейла физического носителя или бага в программе иначе — бекапы, copy on write и т.д..
На самом деле сильных аргументов у меня нету. Я не очень понимаю проблему.
Все приложения, с которыми я сталкивался, и для которым критично логирование, имеют собственные системы логирования (чаще, на удаленный сервер). Но я по своему опыту знаю, что лет 10 назад было принято логи писать в структурированное хранилище (БД), потому что тяжело было что-то сделать с 20 гб плейн текст логов. И это очень похоже на жоурналд.
Сейчас — время облаков, все, обычно, пишется в системы хранения логов, например, на основе эластиксерч. И там тоже структурированный формат. Есть поле месседж, где фритекст, есть поле хост, есть поле ип, есть поле дата, и т.д.. И эти логи тоже нельзя прочитать с помощью вима. И это тоже очень похоже на жоурналд.
Но, повторюсь, я, возможно, далек от проблемы.
> Так ведь в том и дело, что эта инициатива в дебиановском sysvinit уже имелась на момент создания systemd. Ко скриптам инициализации были добавлены LSB-заголовки, в которых прописали зависимости. Sysvinit стартовал демоны параллельно и разруливал зависимости.
Вот об этом я не знал.
Положительные моменты системд
1) я могу написать сервис, который перезапустит бинарь, если тот упадет, и мне не придется для этого использовать ps, grep, kill, rm myapp.pid и т.д.
2) я знаю, что мой сервис стартонет тогда, когда придет времяЕсли другие системы это позволяют, ну что ж, жаль, что большинству о них не известно. Быть может мы бы имели систему инициализации без недостатков системд.
> Хотите пруфов, хотите? Их у меня много. Вся рассылка debian-russian, а ещё располагаю подборкой комментариев с opennet.
Да я и сам могу подбросить. Иногда проще написать while true; do ./mydaemon; done чем разбираться, почему с системд скрипт вообще не стартует. Или почему, при умирании не отрабатывает очистка каких-нибудь ресурсов. Или... Да много я провел времени, чертыхаясь. То диски не отмонтируются. То пользовательская сессия на стартует. За это время можно было бы сотни две баш скриптов написать.
Я — вовсе на фанат системд. И использую его лишь потому, что он поставляется по умолчанию на моем дистрибутиве.
Напоминаю, что я лишь высказал критику к статье о мифах о системд — не всегда весомые аргументы. Ну и я пытаюсь видеть удачные решения в системд.
> В первом случае может быть другой шел, да.Ну это, вообще говоря, признак хорошей архитектуры - возможность относительно лёгкой модификации подручными средствами. Всё-таки переписать 10 тыс строк скриптов задача подъёмная, а переписать 400k строк на Цэ - нет.
> Напоминаю, что я лишь высказал критику к статье о мифах о системд
> — не всегда весомые аргументы. Ну и я пытаюсь видеть удачные
> решения в системд.Это сродни поиску алмазов в известной субстанции. Код subj'а тут уже приводили - это эталон г-кодерства.
> Ну это, вообще говоря, признак хорошей архитектуры - возможность относительно лёгкой модификации подручными средствами.подручными средствами — это уже не важно, к архитектуре отношения не имеет. А возможность использования другого шелла — это прекрасно, это говорит о правильной абстракции. Но и в системд есть возможность хоть баш из юнита вызвать, хоть, питон.
Системд предоставляет более высокоуровневый интерфейс. У этого есть и плюсы, и минусы. 100500 раз уже обсуждалось, не хочу повторять очевидные вещи.Я могу привести признак плохой архитектуры sysvinit — *.pid файлы. Системд они не требуются, потому что он знает, какие процессы породил. А в sysvinit приходилось (может уже нет, вон товарищ выше про зависимости в sysvinit рассказал) сохранять pid на диск, что приводило к неконсистентности: процесс мог давно умереть, а pid файл остается.
Но еще раз, я не защищаю systemd per se. Я призываю к его конструктивной критике. Авторы systemd заинтересованы в его стабильности, пожалуй, даже больше, чем пользователи. Хейтерство — это ну просто неконструктивно, если речь идет об опенсорс.
> Это сродни поиску алмазов в известной субстанции. Код subj'а тут уже приводили
> - это эталон г-кодерства.К сожалению, не видел, но, пожалуй, могу поверить. Такие большие проекты в такие короткие сроки часто получаются не самого высокого качества. Но, с другой стороны, если б все было совсем-совсем плохо, то вряд ли бы проект дожил до 233 версии.
> подручными средствами — это уже не важно, к архитектуре отношения не имеет.
> А возможность использования другого шелла — это прекрасно, это говорит о
> правильной абстракции. Но и в системд есть возможность хоть баш из
> юнита вызвать, хоть, питон.И то, слава богу. Но вы не учитываете возможности полной перестройки системы на совершенно другом скриптовом языке. Т.е. это бы означало полное переписывание unit файлов на другой DSL.
В sysVinit'е абсолютно другой уровень гибкостиё
> Авторы systemd заинтересованы в его стабильности, пожалуй, даже больше, чем пользователи.
В это утверждение невозможно поверить. Я смотрел код systemd, неоднократно его тут цитировал. Так люди, мало мальски заинтересованные в стабильности и обладающие квалификацией хотя бы на уровне табуретки, не пишут.
> В это утверждение невозможно поверить.Это было предположение. Беру слова обратно :)
> Мне не понравился сам лишь подход, что в случае с sysvinit считаем
> строчки "юнит-файлов" (они же скрипты), а в случае с systemd —
> строчки системы инициализации.Хм. Знаете, у меня раж спал, я подумал, и понял, что таки да. Корректности ради код интерпретатора, возможно, стоит включить, потому как systemd инкапсулирует в себя код обработки unit-файлов. То, что интерпретатор и скрипты возможно заменить - это уже камень в сторону модульности.
>> эти 100к строчек отлаживали последние 30 лет или около того
> С таким подходом никогда нельзя разрабатывать что-то новое.Я не совсем это имел в виду. Речь, скорее, о надёжности инструмета. Инструмент, отлаженный за несколько десятилетий, вызывает больше доверия.
А по поводу разработки нового, то я думаю так. Единственное оправдание разработки нового, это наличие задач, не решаемых старым инструментом.> Конструктивно говорить, что в системд есть баги (и это правда),
> говорить какие именно, и тогда их будут фиксить.Так ведь и говорят. Но фиксится далеко не всё. Разработчики уделяют куда больше внимания новым фичам, нежели исправлению существующих дефектов.
>> Раз. (см. #10 - про бинарные логи)
> все зависит от реализации. Современные информационные системы уже давно обходят проблему
> фейла физического носителя или бага в программе иначе — бекапы, copy
> on write и т.д..Да, на самом деле я тут солидарен с Вами. В самой концепции бинарного лога нет ничего плохого. Бинарный лог может позволить хранить много дополнительной информации, которая ускорит поиск по логу и его анализ.
Собственно, речь в статье как раз о том и ведётся. Проблема в реализации бинарного лога в systemd: она не отказоустойчива. Если лог-файл был повреждён, то восстановить его невозможно. Таким образом, если у винчестер начал сбоить, то всё, логи Вы безвозвратно теряете, что может сильно помешать в диагностике неполадок.
Справедливо замечается, что мета-информацию (те же индексы и т.п.) можно было бы хранить отдельно от plain-text лога, что повысило бы отказоустойчивость journald.
> Все приложения, с которыми я сталкивался, и для которым критично логирование, имеют
> собственные системы логирования (чаще, на удаленный сервер). Но я по своему
> опыту знаю, что лет 10 назад было принято логи писать в
> структурированное хранилище (БД), потому что тяжело было что-то сделать с 20
> гб плейн текст логов. И это очень похоже на жоурналд.Двадцатигиговый plain-text лог редко встречается на практике. Это, позвольте сказать, граничные случаи. Для граничных случаев используются специализированные решения, что само собой разумеется.
У нас в компании тоже есть для таких вот задач решения. Например есть сервис отчётов, который сохраняет всю мета-информацию о http(s)-запросах в режиме реального времени и позволяет быстро по ней произвести поиск, когда понадобится. Но это не то, чтобы лог. Это всё-таки база для весьма специфичных нужд (нужд инженеров-безопасников).
> Положительные моменты системд
> 1) я могу написать сервис, который перезапустит бинарь, если тот упадет, и
> мне не придется для этого использовать ps, grep, kill, rm myapp.pid
> и т.д.А, много раз слышал, как systemd-шники гордятся своим watchdog-ом. Но позвольте заметить, что как минимум ещё в начале нулевых Бернштейн написал daemontools - набор утилит, которые именно тем и занимаются, что следят за тем, чтобы сервисы крутились. Уже 15 лет используем в нашей конторе для критичных мест.
> 2) я знаю, что мой сервис стартонет тогда, когда придет время
Я не понял, о чём Вы.
> Если другие системы это позволяют, ну что ж, жаль, что большинству о
> них не известно. Быть может мы бы имели систему инициализации без
> недостатков системд.Да, это по-видимому основная проблема GNU/Linux: наличие огромного выбора. Большинство плавает среди этого выбора и не знает, куда податься.
В systemd, наверное, легче: ты выбираешь его, и за тебя уже выбрали всё, и отступить ни на шаг от этого выбора уже не удастся.
Просто это совсем не тот GNU/Linux, который мы когда-то полюбили. Это GNU/Linux, с которым мы уже ничего не сможем сделать сами, в котором мы ничего не сможем изменить.
Мне такой GNU/Linux нафиг не нужен.>> Хотите пруфов, хотите? Их у меня много. Вся рассылка debian-russian, а ещё располагаю подборкой комментариев с opennet.
> Да я и сам могу подбросить. Иногда проще написать while true; do
> ./mydaemon; done чем разбираться, почему с системд скрипт вообще не стартует.Во-во. Именно для того, чтобы не писать так, я использую djb daemontools. Да вот даже прямо сейчас на моей машине крутится один проприетарный игровой сервер, запущенный именно таким образом.
> Я — вовсе на фанат системд. И использую его лишь потому, что
> он поставляется по умолчанию на моем дистрибутиве.Соболезную.
> Напоминаю, что я лишь высказал критику к статье о мифах о системд
> — не всегда весомые аргументы. Ну и я пытаюсь видеть удачные
> решения в системд.Да, возможно, надо бы слегка освежить статью. Я благодарен Вам за свежий взгляд. Подумаю, что можно сделать для её актуализации.
> Может быть теперь это для Вас "незначительная разница", но имейте в виду,
> что эти 100к строчек отлаживали последние 30 лет или около того.
> Ваша systemd существует в 5 раз меньше, а весит в
> 3 раза больше.Я бы не сказал, что за bash уж так нужно биться. Язык shell серьёзно устарел, но обладает рядом уникальных фич, ака ленивость + мегапараллелизуемость.
SysVinit как раз хорош тем, что позволяет заменить bash на любой другой скриптовый язык соответсвующей мощности, скажем, make. Можно, в принципе, сделать что-то более-менее современное на базе Хаскелля или Ocaml'а (язык, разумеется, не в прямую использовать).
>> Может быть теперь это для Вас "незначительная разница", но имейте в виду,
>> что эти 100к строчек отлаживали последние 30 лет или около того.
>> Ваша systemd существует в 5 раз меньше, а весит в
>> 3 раза больше.
> Я бы не сказал, что за bash уж так нужно биться. Язык
> shell серьёзно устарел, но обладает рядом уникальных фич, ака ленивость +
> мегапараллелизуемость.Согласен. Лично мне больше нравится zsh. Там реально меньше шансов ошибиться. Но чтобы серьёзно что-либо утверждать по данному вопросу, мне стоило бы сначала изучить больше шеллов. Я сейчас, увы только три знаю.
> Можно, в принципе, сделать что-то
> более-менее современное на базе Хаскелля или Ocaml'а (язык, разумеется, не в
> прямую использовать).По-моему мы уже это где-то обсуждали, и не пришли к единому мнению, что же мы хотим привнести в новый язык. Я не очень понимаю, где же нам пригодится строгая типизация в замене shell-а.
На Ocaml было бы очень просто сделать любой DSL (ocamlyacc/menhir + ocamllex в помощь). Но разве что для прототипа. У Ocaml будет слишком большой рантайм, чтобы эффективно форкаться.
> На Ocaml было бы очень просто сделать любой DSL (ocamlyacc/menhir + ocamllex в помощь). Но разве что для прототипа. У Ocaml будет слишком большой рантайм, чтобы эффективно форкаться.Я имел ввиду, что мы берём язык, а не реализацию, из которого уже делаем другой язык. Т.е. про runtime на данном этапе речи нет.
> Я не очень понимаю, где же нам пригодится строгая типизация в замене shell-а.
Дополнительные проверки - shell часто используется для запуска тяжёлых задач, работающих сутки. Если нет хорошей статической типизации, приходится тестировать все ветки исполнения, что может растянуться на неделю, если не писать обвязки-заглушки.
>>Он просто работает. Причем и на машинах с субжом.Разумеется; я сейчас с такой машины и пишу.
Я имел в виду: не собираются ли разработчики, не дай бог, его забросить.
Для таких случаев всегда можно взять что-нибудь другое, начиная с upstart, проходя через runit, заканчивая скриптом на шелле.
А кстати, да, пусть свой systemd-kerneld пилит. Торвальдс, всё равно, его патчи в ваниллу не пустит. Так что, пусть пилит в одно рыло.
> А кстати, да, пусть свой systemd-kerneld пилит. Торвальдс, всё равно, его патчи
> в ваниллу не пустит. Так что, пусть пилит в одно рыло.Кстати о пересипективах s-d! Линус в '91ом на своей 386sx запилил терминалку -- в '2014-ом случился ibm с "перспективами" на миллиардом. В 2010ом ("Sievers started the project to develop systemd in"~~WP:s-d) оно началось с "миллиардами" персперкив Рх -- ...значит, году, эдак, к .... ... ...... 2033-ему Ленарт допишет его до ядра терминалки на 386sx! ...в комнате студ.общаги?! ....в маленькой европейчкой стране.
> А кстати, да, пусть свой systemd-kerneld пилит. Торвальдс, всё равно, его патчи
> в ваниллу не пустит. Так что, пусть пилит в одно рыло.Пустит, не пустит, какая разница. Ванильное ядро в любом случае - переусложенный блоб.
Истинные юниксоиды уже давно планируют переписать его на баше, чтобы было гибко и прозрачно.
> Истинные юниксоиды уже давно планируют переписать его на баше, чтобы было гибко
> и прозрачно.Осторожно, среди хейтеров системд очень много фанатов микроядра.
> когда уже Поттеринг свое ядро запилитточно, и уйдёт на х..р из linux
"А сейчас мы попробуем со всей этой фигнёй взлететь"
> "А сейчас мы попробуем со всей этой фигнёй взлететь"=А сейчас вы всю эту фигню будете тестить=
Тестить? Это, пожалуйста, к команде ядра. Они умеют и делают, да
>> "А сейчас мы попробуем со всей этой фигнёй взлететь"
> =А сейчас вы всю эту фигню будете тестить=:( Debian - "задрав штаны бежать" https://piware.de/post/2017-02-25-test-systemd-pre-233/
Спасибо systemd и лично Леннарту Поттерингу. Без него я бы никогда не нашел в себе сил перейти на FreeBSD.
Изен, залогинься:)
Попробуй CRUX. Freebsd-like система портов, ядро собираешь по-своему.
> Попробуй CRUX. Freebsd-like система портов, ядро собираешь по-своему.На GuixSD же! GNU!! Бесплатный бонус: Они уже переписали pid(1) на LISP. Спешите---
А вот попрошу Вас уточнить какой именно ЛИСП, пожалуйста.
>какой именно ЛИСПТот, который https://www.gnu.org/s/shepherd/ GNU Guile scheme.
тогда уже гента или слака ;)
ортодоксальнее и прозрачнее(да и легковеснее, тоже)некуда, ну акромя LFS, нарное(и всяких DSL, TinyCore, Puppy мутаций и тп).
> тогда уже гента или слака ;)
> ортодоксальнее и прозрачнее(да и легковеснее, тоже)некуда, ну акромя LFS, нарное(и всяких
> DSL, TinyCore, Puppy мутаций и тп).Ты просто CRUX не пробовал.
LFS > CRUX > Slackware > [всё остальное]
А не проще было вместо этой херовой толпы фичей запилить в системды systemd-sysv-initd и решить головняки на корню ? Дарю идею.
>новые опции монтирования в fstabТакой весь передовой systemd всё ещё использует такой архаизм как fstab? ;)
>>новые опции монтирования в fstab
> Такой весь передовой systemd всё ещё использует такой архаизм как fstab? ;)Да, он разбивается на несколько целей монтирования, в результате у системных служб можно выстраивать зависимости. Например, если в fstab есть монтирование /home, создаётся цель var.mount. Если требуется зависимость от примонтированного /var, то в unit-файле пишется:
After=var.mountТак создаются зависимости. Система крайне удобная по сравнению с SysV, где зависимости приходилось делать ручками и они были слишком сложными из-за отсутствия стандартных средств, которые сейчас предоставляет systemd.
>>>новые опции монтирования в fstab
>> Такой весь передовой systemd всё ещё использует такой архаизм как fstab? ;)
> Например, если в fstab есть монтирование /home, создаётся цель var.mount.Опечатался, home.mount. var.mount - для /var
что вы рассказуете противно слушать. какие нафиг зависимости от примонтированного /var, когда у вас всех точек монтирования бут, рут и темп. вы когда мерждили статик бин и бин с юзером, всем так и рассказывали - ето анахронизьм и долой с парохода современности, с нынешними объемами саташечек ето неактуально. а тут вдруг - зависимости от примонтированного вар ах ах.
> что вы рассказуете противно слушать. какие нафиг зависимости от примонтированного /var,Например, var-tmp.mount.
Про встраиваемую технику слыхал? :)
А что, кто-то ставит Debian + systemd на встраиваемую технику? Каждой задаче - своё решение.
> А что, кто-то ставит Debian + systemd на встраиваемую технику? Каждой задаче
> - своё решение.Да, я занимаюсь такой разработкой в частности. Могу сказать, что systemd очень удобная система в таком случае, но есть ещё некоторые недостатки: система ещё недостаточно гибкая. Например, не позволяет назначить сервису пользователя из файла конфигурации сервиса. Либо жёстко прописывается в unit-файле, либо через шаблоны unit-файлов, что не всегда подходит, либо через костыль в виде su, куда можно передать переменные из файла окружения.
Одно из преимуществ, полученных от systemd - скорость загрузки. По сравнению с платформой на базе SystemV скорость загрузки выросла в несколько раз за счёт параллельной загрузки сервисов и собственного порядка загрузки.
Может быть у вас ещё и SSD, помимо сата? Это вам для размышлений над монтированием /var, /var/tmp и /home не в embedded.
>Все поставляемые в составе systemd скрипты на языке PythonГде-то я это уже видел.
Нет.. нет.. нет.. остановите землю! Этот *пип* *бип* Джамшут и изобретатель кубического колеса, он же как Мейзуллина и Пилонов в одном лице.Господь пошли ему долгие дни.. (годы нет нужды). Чтобы у него был полон дом устройств интернета-вещей с 200MHz и 32 Мб озу с установленными на них его же сыстемД
640кб хватит всем? Вас жаба задушила поставить в ваш ембеддед 512М вместо 32М, доплатив аж целых 1$ (в случае очень крупного опта)? Ну и да - для этих вещей есть бизибокс.
Тэорэтик - в сад!
>>Все поставляемые в составе systemd скрипты на языке Python
> Где-то я это уже видел.В новости "Hg переходит на git".
Андрейка, а ты злой :)
> Все поставляемые в составе systemd скрипты на языке PythonЯву туды надо. Чтоб кроссплатформенно и с прицелом на захват винды (а потом и всего мира, чо уж там...).
>> Все поставляемые в составе systemd скрипты на языке Python
> Яву туды надо.Слишком юниксвейно.
>>> Все поставляемые в составе systemd скрипты
>> Яву туды надо.
> Слишком юниксвейно.Не ту яву. https://developers.redhat.com/blog/category/programming/dot-net/ . https://developers.redhat.com/blog/tag/dot-net/ . https://developers.redhat.com/blog/category/programming/c-sharp/ . https://developers.redhat.com/blog/tag/asp-net/ . https://developers.redhat.com/blog/tag/microsoft/
Общее количество опций и параметров - сколько там уже нулей?
> В systemd-mount добавлена опция "--umount" для отмонтирования разделов;Простите, а раньше как нужно было ФС размонтировать?
systemctl mount systemd-mount --umount
> systemctl mount systemd-mount --umountПочти.
systemctl stop blabla.mount
Когда-то был против, потому что нравился upstart (потому что без баша и декларативно и в дистрибе, на котором сижу). Потом всё решили за меня и пришлось скачать http://wiki.opennet.ru/Systemd_%D0%B4%D0%... и изучать. Какой же он крутой! Никакого bash-петушения, декларативное описание сервисов, drop-in конфигурации и т.д. Логи все на месте (не надо верещать, что в бинарном формате, всё равно даже текстовые смотрите с помощью отдельной утилиты). И всё это просто работает!
> Никакого bash-петушения, декларативное описание сервисов,
> И всё это просто работает!Где-то я это уже слышал. Кто сказал Windows?
Когда столкнетесь с не совсем стандартными зачами, вспомните и про "bash-петушения" и про "просто работает"...
> Когда столкнетесь с не совсем стандартными зачами, вспомните и про "bash-петушения" и
> про "просто работает"...Не вспомнят. Они скажут начальству "это невозможно", начальство пожмёт плечами, и всё замнётся.
Очень удобный инструмент для корпорастов: если явно не прописано, как с помощью инструмента сделать то-то, значит этого сделать нельзя. Если прописано, но не работает, как надо - значит багу разработчикам.
Такой подход, правда, превращает сисадмина в обезьянку, бездумно жмущую на кнопки в определённой последовательности. Грустно, конечно, но зато посмотри, как они радуются!
> Такой подход, правда, превращает сисадмина в обезьянку, бездумно жмущую на кнопки в
> определённой последовательности.А, собственно, вам не стыдно все еще считать админство рокетсайнс и безумным страстным творчеством? При наличии достаточных железных ресурсов все админство сводится к "убить по вотчдогу ноду, перезапустить".
>Никакого bash-петушения,Позовите Гарета, Сару и Аврору -- у нас жертва харасмента.
Я стесняюсь спросить, если скрипты на баше - это харрасмент, то что же тогда конфиги sendmail?
>если скрипты на башеНет, разве это не тебя там выше "петушения" и пр.камингауты беспокоили, не стесняйся?
> - это харрасмент
> Я стесняюсь спросить, если скрипты на баше - это харрасмент, то что
> же тогда конфиги sendmail?Садомазо. Не удивительно, что ditched.
>Я стесняюсь спросить, если скрипты на баше - это харрасмент, то что же тогда конфиги sendmail?Скрижали дьявола! Истинно вам говорю! :-)
> Логи все на месте (не надо верещать, что в бинарном формате, всё
> равно даже текстовые смотрите с помощью отдельной утилиты).Проблема бинарного лога не в том, что с ним работать сложнее, а в том, что если он побьётся, то его невозможно восстановить.
Не сложнее чем побившийся /var/log/daemon.1.gz.
> Не сложнее чем побившийся /var/log/daemon.1.gz.Хех. Хорошая попытка, но у того же logroate компрессия по умолчанию выключена. Если демон хочет её включить - это делается явно. Чтобы выключить - надо просто закомментировать строку в /etc/logrotate.d/
Существенные изменения в 233 есть. Пожалуй системд стоило другую нумерацию ставить, где видно "мажорная.минорная.баг фиксы", и эта была бы можорная.> В таймерах (.timer unit) добавлена возможность указания времени относительно конца месяца через использование разделителя "~" вместо "-" между днём и месяцем. Например, "*-02~03" приведёт к срабатыванию таймера за три дня до конца февраля.
Бред какой-то, зачем ставить опцию, которая заведомо делает что-то на 3 дня раньше. Запихнули бы рандом чтоли =)
>Запихнули бы рандом чтоли =)Остановитесь! Ведь так и до скриптов не далеко?? Нужно деражаться11111
Вот так админы локалхоста и палятся.
# eselect profile set hardened
# USE="-systemd" emerge --newuse systemПривет сторонникам systemd
> # eselect profile set hardened
> # USE="-systemd" emerge --newuse system
> Привет сторонникам systemdПраильно! Так их! :)
Package: *systemd*
Pin: release *
Pin-Priority: -1
233 версия, а restart (ExecRestart) сервисов до сих пор нет умеет :-)