Выпуск Systemd 243 с устранением уязвимостей

А назови-ка мне хотя бы одну конструкцию закрепленную синей изолентой?

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

Всего-то надо знать, как писать pidfile, брать первый аргумент и запускать/убивать процесс. Даже без убийства обходимо. Опционально знать про if, man test и функции. Можно даже без case обойтись.

А потом ваш скрипт прибьёт ни в чём не повинный процесс, потому что демон давным-давно упал, и его PID занял совершенно другой процесс.

В том-то и дело, что задача написания init-скрипта только на первый взгляд кажется такой простой - но когда начинаешь погружаться в задачу, то быстро понимаешь, что написать init-скрипт надёжно и правильно очень сложно.

И это уже не говоря о совершенно никакой расширяемости init-скриптов: чтобы поместить сервис в своё сетевое пространство имён, сделать приватный каталог и т.д. - надо написать немаленькую такую простыню.

Слежение за процессами, параллельный запуск и прочее вполне себе есть в каждом runit, man-страницы к которому просты и ясны, сборка которого проста, а в коде которого точно не найдётся столько CVE. DSL накропан в init-системе той же семьи по имени s6. При желании, ты можешь сделать тот же DSL сам, на чём хочешь и гораздо проще.

Т.е. у меня в системе должны быть две системы инициализации с разными утилитами управления, разным синтаксисом настройки и т.д. - вместо одного универсального инструмента? Спасибо, но я как-нибудь systemd обойдусь.

Но подразумевается, так как это и есть голубая мечта ЦА systemd

Мало ли кто что там себе напридумывал...

init-скрипт который сложно написать правильно

Не понятно — осуждают за неосиляторство системды, но считают нормальным не осилить написать инит скрипт. Друже — там в етц скелетон лежит, бери и вписывай свои пути и переменные.

Берёшь питон, добавляешь pygtk/pyqt/tkinter, пишешь гуй и радуешься, что сделал первую действительно полезную для людей вещь на своём питоне.

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

Голубая луна, голубая.

Как тебя переклинило-то.

тачка падает

прямо как линукс с системд...

+

А служба — это общая концепция

https://www.youtube.com/watch?v=cxdZrYr9Lec

Пример, чтобы разницу ощутить. https://wiki.znc.in/Running_ZNC_as_a_system_daemon

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

Ну по ссылке читабельные и понятные любому нормальному админу скрипты, и какая-то непонятная ini хрень - надо читать двухсотстраничный мануал, чтоб понять что найти что такое «WantedBy»...

Я вижу тут разницу только в том, что копипастить надо то или иное в зависимости от окружения. Ды нет, я то в сисьдэ нормально плаваю, решения гуглятся хорошо. Но осадочек в том, что дистров с реально честным выбором (без сись) — раз два и обчёлся.

«Хотя нет, это ж опенсорс виноват, а у тебя есть дела поважнее, аналитика с рекламных трекеров и парсинг чужих писем, например. Или ещё какой-нибудь SaaSS. Правда ведь, полезные и нужные для людей вещи?»

Ходишь в рясе с логотипом Линукс и машешь кадилом ?

Но осадочек в том, что дистров с реально честным выбором (без сись) — раз два и обчёлся.

Так раньше его вообще не было. Но тут появился systemd и все сразу озаботились отсутствием выбора.

Это задача не sysvinit, а враппера.

Вот вам простейший демон, делающий классический double fork:

#include <errno.h>
#include <error.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>

int main()
{
    // Create the first child process
    pid_t child_pid = fork();

    if (child_pid < 0)
        error(EXIT_FAILURE, errno, "cannot fork");

    // Exit the parent process
    if (child_pid != 0)
        return EXIT_SUCCESS;

    // Create a new session to disconnect from the controlling terminal
    pid_t sid = setsid();

    if (sid < 0)
        error(EXIT_FAILURE, errno, "cannot create a new session");

    // Now create the second child to stop being the session leader
    child_pid = fork();

    if (child_pid < 0)
        error(EXIT_FAILURE, errno, "cannot fork");

    // Exit the first child
    if (child_pid != 0)
        return EXIT_SUCCESS;

    /*
     * Real daemon code starts here.
     */

    // Wait 60 seconds
    sleep(60);

    // Exit with random non-zero exit status within [1, 10] range
    srand(time(NULL));
    return rand() % 10 + 1;
}

Он ждёт минуту, а затем завершается с кодом выхода из сегмента [1, 10].

Продемонстрируйте, как вы сможете определить код выхода в sysvinit.

Раньше выбор был. Теперь нет (очень мало — в маргинальных дистрах). На чём ты меня поймать то хочешь?

А к чему тогда нужна эта сисьдэ прослойка?

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

Зайдём от обратного: можно было бы написать одну портянку на баше, которая стартует этот комбайн, который занимается всем тем что уже и так поглотил — кому нравится то использовали бы, кому нет — вырубить/удалить было бы легко.

Для задач отслеживания процессов (что как бы и есть одна из основных задач системы инициализации) необходимо быть PID 1.

предоставляющей нормальный интерфейс

Позволяющий писать портянки дальше, будучи ненужной прослойкой.

необходимо быть PID 1

Верно, и если родительский процесс завершился, то именно пид 1 может/должен/будет ждать код завершения.

Второй форк ОБЯЗАН (для родной или альтернативной обвязке его обслуживания) создать пид файл или иным способом сообщить миру свой пид, т.к. не сообщив его, при завершившихся родителях, единственное место откуда можно понять что там произошло — это инит с пид 1. Так что твой пример — это «классический» кусок говна завязаный на единственный и не всегда доступный способ контроля.

«Да, всё правильно, это конечная точка следования по пути systemd. Оно им «не нужно». У них есть гуй, который удобнее и быстрее. »

Если бы не гуй, вы бы тут не писали.

Любой нормальный разработчик давно бы откатил изменения если бы узнал что ченчж ломает систему

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

Раньше выбор был. Теперь нет

Кто платит тот и танцует… а остальные плачут.

Агась (( Хнык-хнык...

Производители железа фичу заказали, чтоб искусственное старение лучше шло, а продажи росли?

DummyBoy ★ (04.09.19 06:10:01)

Тот редкий случай, когда ник подобран идеально.

Наконец-то добавили магазин?

Блин, это гениально! Я настолько тупого индивидуума со школы не встречал: был у нас тип, который на уроке физики ржал, потому что омега на жёппу похожа. Потом его в спецшколу перевели наконец-то. Жаль контакт не сохранился - вы бы идеально друг дружке подошли :-D

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

p.s.

специально для особо одаренных, которые читают последний коммент и бегут спорить: это не мое мнение, я не собираюсь его отстаивать и т.д. и т.п. и да, простые конфиги я люблю, но вцелом мне все это совсем не нравится.

Позволяющий писать портянки дальше, будучи ненужной прослойкой.

Во-первых, «позволяющий» не значит «заставляющий».

Во-вторых, вы придуриваетесь или правда не понимаете разницу между минимальным shell-кодом конкретно для запуска (что нужно редко и занимает обычно пару строк) и полноценной shell-портянкой для обеспечения работы системы инициализации? Это вообще разные задачи.

Второй форк ОБЯЗАН (для родной или альтернативной обвязке его обслуживания) создать пид файл или иным способом сообщить миру свой пид, т.к. не сообщив его, при завершившихся родителях, единственное место откуда можно понять что там произошло — это инит с пид 1. Так что твой пример — это «классический» кусок говна завязаный на единственный и не всегда доступный способ контроля.

Речь шла о коде выхода - при чём здесь ваш PID-файл?

я то в сисьдэ нормально плаваю

У меня тоже сложилось впечатление, что ты из тех, кто не тонет.

осадочек в том, что дистров с реально честным выбором (без сись) — раз два и обчёлся

А с какого это перепугу разработчики должны вдруг удовлетворять твои хотелки? Тех у кого «решения гуглятся хорошо» - как грязи, смысл каждому капризуле сопли утирать?

Интересно, можно ли поиграться с cgroup так, чтобы также успешно «демонизироваться» и выйти из под контрля systemd?

Почему «классический демон» может играться c session id и process group id, но не может с cgroup?

понятные любому нормальному админу скрипты
start-stop-daemon

Это ты пошутил так?

А @crypt говорит, что-де systemd только к версии 243 дошёл до того, что все остальные якобы всегда умели и делали.

конкретно в том посте я критикую не systemd, я прямо пишу, что сомневаюсь в компетенции создателей-программистов. я не пишу, что какие-то сервисы работали как-то иначе (ну нет этого в моем сообщении). просто сообщение в чейджлоге выглядит как очевидная ошибка проектирования. ну ты вот мне отвечаешь, что мол оно как-то по-другому работало. ну мне нечего возразить, так как я хз. я с systemd завязал сразу после того, как оно не смогло прочекать фс и загрузиться. ну ок, я признаю, что ошибки в программах исправляются. если люди это назвали 243 релизом, то я бы назвал 0.243 бета релизом. ну разгребайте, изучайте... я уже обозначил, что мне проще freebsd изучить и использовать старые парадигмы админства, чем переделывать все на новый декларативный подход, потому что microsoft и редхат теперь руководствуются новыми данными статистики. я готов постебаться над чейжлогом, но не готов следить за всем этим бредом в продакшене. в какой-то момент systemd допишут, появится новый systemd/Linux (недавно слышал, что даже grub можно уже выкинуть и грузиться сразу через efi+systemd) и дефолтное поведение перестанет меняться.

Раньше выбор был.

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

А потом ваш скрипт прибьёт ни в чём не повинный процесс, потому что демон давным-давно упал, и его PID занял совершенно другой процесс.

опционально надо знать про if

Я думаю, тупая проверка имени процесса может нас в какой-то мере спасти.

надёжно и правильно

Написать демон, который делает всё на свете и делает это надёжно и правильно гораздо сложнее.

И это уже не говоря о совершенно никакой расширяемости init-скриптов: чтобы поместить сервис в своё сетевое пространство имён, сделать приватный каталог и т.д. - надо написать немаленькую такую простыню.

Немаленькая простыня — это вызов nsenter? У меня сейчас лежит «немаленькая простыня» на пять-семь строк на шелле (вызывает vpn в неймспейсе с ресолвингом капчи через OCR) и смеётся над тобой. Если её чуть-чуть доработать, её вполне можно доработать под вызов из инитскрипта любой системы инициализации в том ключе, в котором ты хочешь. Как минимум в тех двух инитах, с которыми я сталкивался.

Это не никакая расширяемость. Это расширяемость, которая тебе и не снилась. Враппер тут, хэлпер там и готово. А если решил сменить init-систему на другую вменяемую (или даже невменяемую), твои инструменты всегда при тебе. И я не говорю о том, что их не только из init стоит запускать.

Т.е. у меня в системе должны быть две системы инициализации с разными утилитами управления, разным синтаксисом настройки и т.д.

Это две разные init-системы из одной семьи. DSL из s6 — универсальный инструмент, который можно прикрутить к runit, к примеру.

Универсальный инструмент — это то, что можно использовать в широком смысле. Можно ли широко использовать груду узконаправленных костылей из INI-файлов? Нет. Можно ли использовать, к примеру, sudo, шелл или nsenter везде, где можно и где нельзя, для самых разных целей? Можно.

Второй форк ОБЯЗАН ...

systemd как-то без этого живёт и функционирует.

Тот же znc вообще запускается с параметром -f и не форкается никуда. Адовое поделие dropbox может в процессе работы даже обновиться и перезапуститься, но всё равно контролируется и может быть корректно завершено. При этом логи из stdout/stderr пишутся и могут быть просмотрены.

Да та же прослойка для поддержки запуска скриптов из /etc/init.d. Скрипт отработал, запустив демона, и завершился, а порожденные им процессы висят в статусе.

Они так и так из своей группы никуда не денутся.

А вот с pid-файлами я в своё время хлебнул горя, когда status говорил, чтоб всё ок, а на деле проверял наличие файла и всё. Или не удалённый файл из-за проверок в скрипте мешал запуску демона.

p.s.

поскольку тред говнозакидательский (и я уже вижу 3 сообщения из 33), товарищи анонимы, напоминаю, что вы в игноре. если кто-то решить кинуть какашкой, проверяйте в профиле, нет ли вас в игноре тоже.

Во-первых, «позволяющий» не значит «заставляющий»

Но именно безальтернативно заставляющий писать декларативщину которая позволит вызвать портянку.

не понимаете разницу

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

Речь шла о коде выхода - при чём здесь ваш PID-файл?
или иным способом сообщить миру свой пид

... для того, чтобы отследить состояние можно было не только из пид 1.

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

Мне кажется, что ты это будешь ещё несколько раз повторять в разных вариациях?

специально для особо одаренных

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

мой пересказ слов редхатовца плюс мой бред

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

лор есть лор

Ну вот не проявлял ранее человек признаков душевных заболеваний. Потом начал бегать по лору и кричать про радиацию, потом когда его флуд и оффтоп выпилили начал бегать и кричать про кровавую модерастию. Вчера начал галюцинировать философскими трактатами про сыстемдэ и орды отбросов. А что будет завтра, или следующей весной?

товарищи анонимы, напоминаю, что вы в игноре.

«Я бежал за вами три дня, чтобы сказать, насколько вы мне безразличны»

Я думаю, тупая проверка имени процесса может нас в какой-то мере спасти.

Если так болит обложиться соломкой — кроме пид файла с именем процесса и пидом в нём, можно ещё взять таймстамп с микросеками от старта процесса.

ахаха и не говори

Второй форк ОБЯЗАН ... systemd как-то без этого живёт и функционирует.

Потому что оно пид 1 и может отслеживать коды возврата от безродных процессов.

и завершился, а порожденные им процессы висят в статусе

Но мы имеем пид файлы и можем отслеживать состояние не только через пид 1.

не удалённый файл из-за проверок в скрипте мешал запуску демона

Да, бывает такое. А почему демон упал? Надо ведь демона фиксить значит.

«поскольку тред говнозакидательский (и я уже вижу 3 сообщения из 33), товарищи анонимы, напоминаю, что вы в игноре. если кто-то решить кинуть какашкой, проверяйте в профиле, нет ли вас в игноре тоже.»

Только сейчас обратил внимание на вашу аватарку. Прошу прощения, сэр.

Мне кажется, что ты это будешь ещё несколько раз повторять в разных вариациях?

ну, буду повторять, потому что часто соседние сообщения не читаются, забываются и т.д. это довольно логичное поведение на лоре.

начал бегать и кричать про радиацию

нэ мой проблема, нэ видэл. тэму нэ поддерживаю и кто такой радиацэй нэ знаю. я ток за systemd могу. я к тому, что ты игнорь, что не нравится и все. нафиг [чужие] какашки по форуму размазывать.

Я вот сильно удивлён

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

мне потом приходить на работу и иметь дело с менеджментом, которому «прошили» мозги их евангелисты

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

Потом в функцию и делать source по необходимости.

Вы, главное, из футляра не выходите ни в коем случае.

А почему демон упал?

Электричество пропало, пьяный админ Вася ресет жахнул. Вот остался он и всё тут, а программист такое не предусмотрел, а мейнтейнер на него понадеялся.

Ну по ссылке читабельные и понятные любому нормальному админу скрипты, и какая-то непонятная ini хрень - надо читать двухсотстраничный мануал, чтоб понять что найти что такое «WantedBy»

Скрипты sysvinit перестали быть понятными и легкомодифицируемыми из-за возросшей сложности систем. Увы. Не будь systemd все равно пришлось бы придумывать альтернативу существующей инициализации. Прогресс требует новых инструментов.

Ты прямо как продаван облаков. Та же риторика и то же стремление заставить людей платить за отдельный софт в контейнере.

Я думаю, тупая проверка имени процесса может нас в какой-то мере спасти.

Вот именно что тупая, поскольку ещё ничего не гарантирует: это может быть процесс с таким же именем, но от другого экземпляра сервиса (что легко реализуется в случае, когда демон порождает множество одноимённых worker-ов - по одному на каждое соединение).

А если у вас демон, который плодит множество дочерних процессов, то неплохо было бы эти дочерние процессы тоже прибить, если родитель с этим не справился. А если не дай бог эти дочерние процессы ещё и форкаются и тем самым убегают от родителя, то отследить их вообще нереально.

В скриптах ещё и такое встречается - думаю, не нужно объяснять, в чём здесь косяк? (Подсказка: пользователи KDE будут очень благодарны.)

В общем, есть множество граничных случаев, без учёта которых система остаётся ненадёжной конструкцией из killall и sleep 1, и учесть которые очень сложно и геморно в скрипте. Скрипты вообще плохо приспособлены для написания не строго последовательно исполняемого кода.

Немаленькая простыня — это вызов nsenter

Да. Всё равно придётся править скрипт, с вытекающими отсюда последствиями при обновлениях. Костыль в виде /etc/default не просто так появился, но для таких задач непригоден.

Враппер тут, хэлпер там

...и в продакшн! Ох, разгребать потом после таких вот любителей строить из палок и изоленты...

Задачка вам в ответ: есть демон, процесс которого неожиданно завершился, - как в sysvinit узнать его код выхода или сигнал, который привёл к завершению?

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

Не важно что мы пишем, однострочник или мегапортянку — мы её в любом случае пишем.

Угу, «неважно, что мы пишем: hello world или ядро ОС - мы его в любом случае пишем».

... для того, чтобы отследить состояние можно было не только из пид 1.

Как наличие PID-файла поможет узнать, от какого сигнала грохнулся процесс?