А был ли мальчик?

package containing this bug has never been released.

эпично

энтерпрайз такой энтерпрайз, ubuntu server во все поля :)

Мдаааа... Похоже, бывшие разработчики Bumblebee перешли на сквид и решили, что гулять, так гулять. На всю катушку!

Энтерпрайз! Штабильность! Поддержка! Выбор профессионалов!

Let the sratch begin!

BTW, не то, чтобы я на что-то намекал, но systemd такую ситуацию практически исключает.

Энтерпрайз! Штабильность! Поддержка! Выбор профессионалов! Куд-кудах!

Fixed

Я сознательно опустил очевидное. ☺

Обработка исключения

BTW, не то, чтобы я на что-то намекал, но systemd такую ситуацию практически исключает.

Простите, каким образом?

Простите, каким образом?

Там нет инитскриптов на баше, в которые может затесаться что-то вроде rm -rf / var/run/squid/squid.pid.

Не ошибается тот кто ничего не делает

Там нет инитскриптов на баше, в которые может затесаться что-то вроде rm -rf / var/run/squid/squid.pid.

Оукей, а если при перезапуске нужно удалить старый pid или ещё что-нибудь, как это делает systemd?

прозреваю, что это может быть и очистка кэша сквида такая

Оукей, а если при перезапуске нужно удалить старый pid или ещё что-нибудь, как это делает systemd?

Указываете переменную PIDFILE в юните, и systemd сам её удалит.

прозреваю, что это может быть и очистка кэша сквида такая

Ну, кэш сквида тоже очистился. ☺

А там можно PIDFILE=" -rf /" ?

Очистка кэша

Указываете переменную PIDFILE в юните, и systemd сам её удалит.

А если в более общем виде, если нужно несколько директорий очистить? В сценарии оболочки это может быть

rm -rm /var/cache/squid / /var/tmp/squid

А в systemd с таким же успехом

CACHE_DIRS=«/var/cache/squid / /var/tmp/squid»

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

А там можно PIDFILE=" -rf /" ?

Nope.

А если в более общем виде, если нужно несколько директорий очистить?

Тогда те же грабли. IMHO, таких случаев в принципе стоит избегать. Программа должна уметь корректно работать без всяких инитов.

А там можно PIDFILE=" -rf /" ?

«Not an absolute path, ignoring PIDFILE»

Эскобарd

Программа должна уметь корректно работать без всяких инитов.

То есть systemd в этом отношении в точности такое же говно как и всё прочее говно и наличие или отсутствие в нём возможности/необходимости запуска сценариев оболочки ничего не меняет.

И таки systemd должен уметь работать с тем ПО которое есть, а не отказывать в запуске программ, которые ему по каким-то причинам не нравятся.

Если systemd может хоть что-то делать, то он сможет делать и вредные вещи, в том числе по ошибке.

В 99% случаев достаточно встроенного в юниты функционала, где вероятность подобного факапа близка к нулю. Да, в оставшемся 1% случаев можно также выстрелить себе в ногу, но шансов на это гораздо меньше, чем с инитскриптами. Инитскрипты можно сравнить с заряженным пистолетом, лежащем на столе, тогда как в случае системд этот пистолет разряжен и в сейфе, ключи от сейфа в дальнем углу антресолей.

Логика работы софтины, вынесенная на уровень рутового init скрипта, суть есть дикий быдлокод.

или отсутствие в нём возможности/необходимости запуска сценариев оболочки ничего не меняет.

Сабжевая ошибка не проявила бы себя, если сбрасывание прав произошло бы сразу (как systemd), а не при старте бинарника демона.

прозреваю, что это может быть и очистка кэша сквида такая

При перезапуске сквида? Не жирно ли? При большом количестве пользователей там с десятки гигов актуального кэша может быть.

RedHat на проводе

В 99% случаев достаточно встроенного в юниты функционала, где вероятность подобного факапа близка к нулю.

Это вы маркетологов RedHat'а цитируете? Вероятность факапа близка к нулю, однако ж раз в год и палка стреляет, а перезапуск squid'а трёт файлы.

Да, в оставшемся 1% случаев можно также выстрелить себе в ногу, но шансов на это гораздо меньше, чем с инитскриптами.

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

Анти-быдлокод

Логика работы софтины, вынесенная на уровень рутового init скрипта, суть есть дикий быдлокод.

И? systemd от этого спасает? Нет, не спасает. Я не защищаю сейчас squid, я осуждаю защитников systemd, который в подобной ситуации был бы столь же бесполезен сколь и любая другая программа для запуска демонов.

ПЕРЕЗАПУСТИ СВОЙ СКВИД, БЫСТРО, БЛЕАТЬ, НЕТ ВРЕМЕНИ ОБЪЯСНЯТЬ!

Мне не настолько нечего делать, чтобы изучать девелопмент-версии пакетов сквида в 6.7 шапке )) Скорее всего, конечно, там run-файлы криво удаляются.

systemd от этого спасает? Нет, не спасает.

Т.е. «rm -rf /» вызванный с правами squid удалит всё из корня?

Меня вот что очень волнует - там никто ничего не тестирует что ли перед выкатыванием пакетов?

Веселый баг +)

Правда это утка, там же в багтрекере написано:

package containing this bug has never been released.

То есть systemd в этом отношении в точности такое же говно как и всё прочее говно

Не понял как это вытекает из моих слов.

И таки systemd должен уметь работать с тем ПО которое есть, а не отказывать в запуске программ, которые ему по каким-то причинам не нравятся.

Оно и умеет. Где-то утверждалось обратное?

Права systemd

Т.е. «rm -rf /» вызванный с правами squid удалит всё из корня?

А при чём здесь squid? В системе с Upstart или OpenRC «rm -rf /» вызванный с правами squid удалит всё из корня?

Обратное верно

Не понял как это вытекает из моих слов.

Тогда те же грабли

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

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

Без systemd такое с лёгкой руки майнтейнера может произойти с любым демоном. С systemd - только с изначально кривыми, да и то вряд ли, как указал shahid.

там никто ничего не тестирует что ли перед выкатыванием пакетов?
перед выкатыванием пакетов?
package containing this bug has never been released.

Кривизна произвольного

Без systemd такое с лёгкой руки майнтейнера может произойти с любым демоном.

С systemd тоже с любым.

С systemd - только с изначально кривыми

С любой другой системой инициализации тоже только с кривыми.

да и то вряд ли, как указал shahid.

Вероятность примерно такая же.

Ключевые слова «с лёгкой руки майнтейнера». Нет никаких оснований полагать, что использование нового языка программирования/конфигурации вместо существующих избавит от вероятности совершения ошибки.

С systemd тоже с любым.

ЛПП. Вот так выглядит systemd сервис squid:

[Unit]
Description=Web Proxy Cache Server
After=network.target

[Service]
Type=forking
PIDFile=/run/squid.pid
ExecStart=/usr/bin/squid -sYC
ExecStop=/usr/bin/squid -k shutdown
ExecReload=/usr/bin/squid -k reconfigure

[Install]
WantedBy=multi-user.target

С любой другой системой инициализации тоже только с кривыми.

Если у сервиса есть PID файл, это не значит, что он кривой. Но это потенциальное место ошибки в инит-скрипте на баше.

Вероятность примерно такая же.

Речь не о вероятности, а о последствиях. Без рутовых привилегий rm -rf / не сработает.

Ключевые слова «с лёгкой руки майнтейнера». Нет никаких оснований полагать, что использование нового языка программирования/конфигурации вместо существующих избавит от вероятности совершения ошибки.

От вероятности такой ошибки - избавит. Не шлангуйте.

ЛПП

Вот так выглядит systemd сервис squid:

Я уже несколько раз пытался увести вас от осуждения конкретного случая squid к более общему. Но вы продолжаете игнорировать возможность совершения множества других ошибок в других местах напирая на одну единственную от которой systemd возможно спас бы. Даже учитывая, что package containing this bug has never been released.

Что здесь может пойти не так?

Любой ментейнер глядя на любой сценарий задаётся тем же вопросом. Да и любой программист тоже. Уверенность в верности неверного ответа не добавляет надёжности.

Если у сервиса есть PID файл, это не значит, что он кривой. Но это потенциальное место ошибки в инит-скрипте на баше.

Я вам уже сказал, что может быть необходимость удалять не единичный файл, но целый набор директорий, и вы даже признали мою правоту, но продолжаете возвращаться к вашему любимому случаю со squid'ом. Частное не доказывает общее.

Речь не о вероятности, а о последствиях. Без рутовых привилегий rm -rf / не сработает.

И по этому поводу я тоже уже отвечал. «rm -rf /» от непривилегированного пользователя работает одинаково при любых системах инициализации.

От вероятности такой ошибки - избавит. Не шлангуйте.

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

Я уже несколько раз пытался увести вас от осуждения конкретного случая squid к более общему.

Да, вы уже несколько раз пытались срулить на то, что, если очень постараться, то ногу можно себе прострелить и из systemd. Только это херовый аргумент.

Уверенность в верности неверного ответа не добавляет надёжности.

Чистая демагогия.

Я вам уже сказал, что может быть необходимость удалять не единичный файл, но целый набор директорий

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

И по этому поводу я тоже уже отвечал. «rm -rf /» от непривилегированного пользователя работает одинаково при любых системах инициализации.

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

Вы опять пытаетесь перейти от обсуждения общего к частному.

Если на краю обрыва поставить оградку, то падать с него будут меньше. Конечно, найдутся гении, которые через неё перелезут, или великаны, которые её не заметят, но это не отменяет факта повысившейся безопасности. Какое, к чёрту, общее и частное?

Стабильнее дистра нет, лол

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

Только я не понял, а зачем кэш сквида очищать при старте системы, а не сквида?

Upd, Оказывается, не только а он просто хотел перезапустить squid (комментарий)

Вероятность примерно такая же.

С systemd сабжевую ошибку можно устроить ТОЛЬКО явно и преднамеренно.

В случае с sysv и прочими bash-поделками, дающими полный рутовый кард-бланш, всё происходящее на усмотрение великой неопределенности и внимательности писателя init-скрипта, что мы и наблюдаем в ОП-посте. Пейсатели init-скриптов почти всегда сбрасывают права только на самом последнем шаге, когда запускается демон, или не сбрасывают вообще, предоставляя это дело демону.

В системе с Upstart или OpenRC «rm -rf /» вызванный с правами squid удалит всё из корня?

В RHEL сейчас Upstart или OpenRC?

removeOldPidD

After install of test packages for RHEL 6.7 - так что автор бага зря суетится - ну подумаешь потестировал :)

Пара комментов кстати подтверждают вопроизводимость в виртуалках.

что там? the website is down?

Логика работы софтины, вынесенная на уровень рутового init скрипта, суть есть дикий быдлокод.

systemd от этого не спасёт (ибо есть костыли), а если бы этого явления не было, то и init скрипты были бы мягкими и шелковистыми.
Более того, так как systemd перезапускает крашищийся сервис, быдлокодеры совсем распояшутся.

То есть systemd в этом отношении в точности такое же говно как и всё прочее говно и наличие или отсутствие в нём возможности/необходимости запуска сценариев оболочки ничего не меняет.

Нет, просто systemd создавался для того, чтобы заменить толстые init-скрипты(на 100 и более строчек), где каждый PIDFILE контролировался кодом на bash, на простые ini-юниты, где ты просто указываешь, где должен лежать этот PIDFILE, и systemd уже сам, православным способом, проконтролирует его создание и удаление. По пути отсеяв всякие ошибки типа rm -rf / var...

Именно поэтому получается быстрее. Потому что вместо bash-скрипта, который постоянно создаёт одноразовые микрофорки(программы из окружения), идут уже вызовы на православных Сях, с распараллеливанием, и всем прочим.

Тем самым, ответственность за написание init-скриптов мягко переложили с плеч разрабов демонов на плечи мейнтейнеров дистрибутива, которые тупо пишуют unitы. А выполнение типичных/базовых для init-скриптов операций, на плечи поделия поцерринга.

// ИМХО, они всё правильно сделали. Единственное, чего делать не стоило, так это делать из сырцев systemd комбайн из разных программ, и принудительно завязывать эти программы на API systemd.

Подведем итоги треда. Что все-таки не нужно?

1. squid

2. rhel

3. /etc/init.d/

4. systemd (хотя, казалось бы, при чем тут systemd)

ППКС Пример того, как политика вмешивается в разработку и всё скатывает... А ошибки в unit'ах таки могут приводить к жутким вещам. Их действительно должны писать мейтейнеры всей системы, а не авторы демонов - а то получится адок...

буду банален и скажу, что нужно всё