История изменений

Ладно, был неправ насчет «неровно облезешь», извини. Ты просто заехал с явной провокацией.

Смотри, micronekodesu сказал дословно следующее: «никогда не видел того, что нельзя было бы сделать в «старом» ините с теми же затратами». Я, как чел познавший боль, не согласился и привел банальный, но вполне реальный пример с дженкинсом. Если ты хочешь запускать его standalone-jar как сервис, то очень быстро столкнешься с ограничениями инитскриптов: отследить pid нельзя из-за трипл-форков, start-stop-daemon абсолютно беспомощен, а делать pkill на stop (это делает инитскрипт, который поставляется с дженкинсом) перестает работать когда дженкинсов больше одного - русская рулетка лол. Передавать дженкинсу параметр, чтобы он светился в имени процесса тоже не выходит. В итоге это всё превращается в занимательные танцы, и тут уже проще поставить Томкат. Но Томкат - это тоже не подарок и секса с ним хватает. Контейнеризация в то время была еще очень далеко от мейнстрима.

Требовать от меня именно моё решение - как минимум некорректно. И ты, и я, и micronekodesu знаем, что задача решается, так или иначе. И неважно решил ли её именно я. Ну, допустим, я - нерюх и не решил, но это не отменяет того, что инитскрипты беспомощны. С systemd вся эта проблема решается ровно за 15 минут с перекурами и без всякого напряга. И вот теперь вопрос: за каким хером я буду ломать себе башку с инитскриптами (причем, заметь, на каждый новый «дженкинс» я буду себе ломать голову по-новому), когда я могу написать юнит из пяти строк и идти заниматься делом вместо того чтобы копаться в окаменелом говнокоде start-stop-daemon?

Те, кто ноют что «нипанятна как работает», «доки хреновые», «сложно» и т.п. - просто слабаки и не видели больших за$%п SMF. Даже launchd, и тот в сравнении с systemd - темный лес. Тех, кто топит за AIX я вообще не могу понять - в пятом аиксе (а это было не так давно) вообще никаких инитскриптов не было и надо было сервисы прямо в inittab засовывать, как диды завещали.

Замена системы инициализации на «системный менеджер» - ну, тут каждый волен сам решать надо ему это или нет. Остальные компоненты systemd кроме pid1 строго опциональны: не нравится - отключи не юзай. Однако, когда мне надо было сделать настоящий хотплаг сетевых интерфейсов, то systemd-networkd оказался для этого самым удобным инструментом. NetworkManager тоже умеет, но требует сильно больше телодвижений.

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

С другой стороны, есть люди, у которых парк машин на слаке или, например, на фрибсд. На ЛОРе есть кто-то, у кого то ли интернет-провайдер небольшой, то ли что-то похожее, и у него сервера на слакваре, вроде. У них все работает уже 15 лет кряду и система инициализации им до одного места. Ну и норм тоже, зачем ломать что-то что работает.

Ладно, был неправ насчет «неровно облезешь», извини. Ты просто заехал с явной провокацией.

Смотри, micronekodesu сказал дословно следующее: «никогда не видел того, что нельзя было бы сделать в «старом» ините с теми же затратами». Я, как чел познавший боль, не согласился и привел банальный, но вполне реальный пример с дженкинсом. Если ты хочешь запускать его standalone-jar как сервис, то очень быстро столкнешься с ограничениями инитскриптов: отследить pid нельзя из-за трипл-форков, start-stop-daemon абсолютно беспомощен, а делать pkill на stop (это делает инитскрипт, который поставляется с дженкинсом) перестает работать когда дженкинсов больше одного - русская рулетка лол. Передавать дженкинсу параметр, чтобы он светился в имени процесса тоже не выходит. В итоге это всё превращается в занимательные танцы, и тут уже проще поставить Томкат. Но Томкат - это тоже не подарок и секса с ним хватает. Контейнеризация в то время была еще очень далеко от мейнстрима.

Требовать от меня именно моё решение - как минимум некорректно. И ты, и я, и micronekodesu знаем, что задача решается, так или иначе. И неважно решил ли её именно я. Ну, допустим, я - нерюх и не решил, но это не отменяет того, что инитскрипты беспомощны. С systemd вся эта проблема решается ровно за 15 минут с перекурами и без всякого напряга. И вот теперь вопрос: за каким хером я буду ломать себе башку с инитскриптами (причем, заметь, на каждый новый «дженкинс» я буду себе ломать голову по-новому), когда я могу написать юнит из пяти строк и идти заниматься делом вместо того чтобы копаться в окаменелом говнокоде start-stop-daemon?

Те, кто ноют что «нипанятна как работает», «доки хреновые», «сложно» и т.п. - просто слабаки и не видели больших за$%п SMF. Даже launchd, и тот в сравнении с systemd - темный лес. Тех, кто топит за AIX я вообще не могу понять - в пятом аиксе (а это было не так давно) вообще никаких инитскриптов не было и надо было сервисы прямо в inittab засовывать, как диды завещали.

Замена системы инициализации на «системный менеджер» - ну, тут каждый волен сам решать надо ему это или нет. Остальные компоненты systemd кроме pid1 строго опциональны: не нравится - отключи не юзай. Однако, когда мне надо было сделать настоящий хотплаг сетевых интерфейсов, то systemd-networkd оказался для этого самым удобным инструментом. NetworkManager тоже умеет, но требует сильно больше телодвижений.

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

Ладно, был неправ насчет «неровно облезешь», извини. Ты просто заехал с явной провокацией.

Смотри, micronekodesu сказал дословно следующее: «никогда не видел того, что нельзя было бы сделать в «старом» ините с теми же затратами». Я, как чел познавший боль, не согласился и привел банальный, но вполне реальный пример с дженкинсом. Если ты хочешь запускать его standalone-jar как сервис, то очень быстро столкнешься с ограничениями инитскриптов: отследить pid нельзя из-за трипл-форков, start-stop-daemon абсолютно беспомощен, а делать pkill на stop (это делает инитскрипт, который поставляется с дженкинсом) перестает работать когда дженкинсов больше одного - русская рулетка лол. Передавать дженкинсу параметр, чтобы он светился в имени процесса тоже не выходит. В итоге это всё превращается в занимательные танцы, и тут уже проще поставить Томкат. Но Томкат - это тоже не подарок и секса с ним хватает. Контейнеризация в то время была еще очень далеко от мейнстрима.

Требовать от меня именно моё решение - как минимум некорректно. И ты, и я, и micronekodesu знаем, что задача решается, так или иначе. И неважно решил ли её именно я. Ну, допустим, я - нерюх и не решил, но это не отменяет того, что инитскрипты беспомощны. С systemd вся эта проблема решается ровно за 15 минут с перекурами и без всякого напряга. И вот теперь вопрос: за каким хером я буду ломать себе башку с инитскриптами (причем, заметь, на каждый новый «дженкинс» я буду себе ломать голову по-новому), когда я могу написать юнит из пяти строк и идти заниматься делом вместо того чтобы копаться в окаменелом говнокоде start-stop-daemon?

Те, кто ноют что «нипанятна как работает», «доки хреновые», «сложно» и т.п. - просто слабаки и не видели больших за$%п SMF. Даже launchd, и тот в сравнении с systemd - темный лес. Тех, кто топит за AIX я вообще не могу понять - в пятом аиксе (а это было не так давно) вообще никаких инитскриптов не было и надо было сервисы прямо в inittab засовывать, как диды завещали.

Замена системы инициализации на «системный менеджер» - ну, тут каждый волен сам решать надо ему это или нет. Остальные компоненты systemd кроме pid1 строго опциональны: не нравится - отключи не юзай. Однако, когда мне надо было сделать настоящий хотплаг сетевых интерфейсов, то systemd-networkd оказался для этого самым удобным инструментом. NetworkManager тоже умеет, но требует сильно больше телодвижений.

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