В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

DevOps Jobs - работа и аналитика

6576 membersпожаловаться на группу
2020 December 26

O

Onlinehead in DevOps Jobs - работа и аналитика
Dmitry Sergeev
статус там. Это просто баш в init скрипте, который запсукается при service service-name status. Что там будет полностью на совести разраба этого скрипта
Так чудесно же. Ровно так же, как совести разраба содержание stdout/err, exit code и так далее.
По зависимостям - да, это и правда удобно. Лично мне надо редко, но удобно. Тут плюс за systemd. Если у тебя все им запускается,конечно:)
источник
16:14пожаловаться#1

DS

Dmitry Sergeev in DevOps Jobs - работа и аналитика
Sebor
sticker.webp
(24.45 Кб)
+
источник
16:15пожаловаться#2

АГ

Александр Григорьев... in DevOps Jobs - работа и аналитика
Dmitry Sergeev
systemd знает о всех перезапусках процесса. Может в зависимости от этого действовать как надо. Ты можешь видеть коды exit статуса. Ты можешь там же посмотреть его stdout/stderr
Вам не кажется, что для реализации обычных сисколлов clone и waitpid(именно это и лежит в основе ветвления процессов) - кода на 230 МБ многовато? Даже с логикой, которую вы привели в пример.
источник
16:17пожаловаться#3

DS

Dmitry Sergeev in DevOps Jobs - работа и аналитика
Onlinehead
Так чудесно же. Ровно так же, как совести разраба содержание stdout/err, exit code и так далее.
По зависимостям - да, это и правда удобно. Лично мне надо редко, но удобно. Тут плюс за systemd. Если у тебя все им запускается,конечно:)
так если мне systemd дает гарантии, что я могу посмотреть статус кода выхода сервиса и что он там писал в stderr/stdout с любым сервисом. Нафига мне выбирать sys v init который не дает никаких гарантий не на что?
Там даже нет гарантий что по service service-name start он попытается запустить процесс. Любая ошибка в баш скрипте, и он тихо отрапортует мол запустил, но ничего не запустит и даже ошибку не выдаст.
источник
16:17пожаловаться#4

AK

Andrey Kartashov in DevOps Jobs - работа и аналитика
Onlinehead
Так чудесно же. Ровно так же, как совести разраба содержание stdout/err, exit code и так далее.
По зависимостям - да, это и правда удобно. Лично мне надо редко, но удобно. Тут плюс за systemd. Если у тебя все им запускается,конечно:)
Каждый велосипедит и костылит, как умеет. Куча проектов не имели своих пакетов Deb/rpm из-за того, что разрабу лень вникать во все тонкости написания инит скрипта.
источник
16:18пожаловаться#5

O

Onlinehead in DevOps Jobs - работа и аналитика
Dmitry Sergeev
так если мне systemd дает гарантии, что я могу посмотреть статус кода выхода сервиса и что он там писал в stderr/stdout с любым сервисом. Нафига мне выбирать sys v init который не дает никаких гарантий не на что?
Там даже нет гарантий что по service service-name start он попытается запустить процесс. Любая ошибка в баш скрипте, и он тихо отрапортует мол запустил, но ничего не запустит и даже ошибку не выдаст.
вы не знаете о существовании set флагов в баше, которые позволяют прервать выполнение при ошибке?
источник
16:18пожаловаться#6

a6

admin 666admin in DevOps Jobs - работа и аналитика
Dmitry Sergeev
эм, pid уже не сущесвтует, у тебя процесс упал, это как поможет? Только не надо рассказывать что можно написать враппер на баше, который будет $? записывать в файлик, а потом service service-name status читать от туда. Как давай щас все sys v init скрипты переписывать
вач на pid и экшн если упало, зачем пид пихать в env если для этого есть уже envof() и state(). Сложности не надо придумывать там где их нет, на мой взгляд. Если есть желание ничего не делать и лениво гадать что будет с демоном из разряда 'на кого бог пошлет" то системд вполне подойдёт.
источник
16:19пожаловаться#7

DS

Dmitry Sergeev in DevOps Jobs - работа и аналитика
Onlinehead
вы не знаете о существовании set флагов в баше, которые позволяют прервать выполнение при ошибке?
Я то знаю, но какие гарантии дает sys v init? Откуда есть уверенность что там в скрипте сделано все как надо?
источник
16:19пожаловаться#8

DS

Dmitry Sergeev in DevOps Jobs - работа и аналитика
admin 666admin
вач на pid и экшн если упало, зачем пид пихать в env если для этого есть уже envof() и state(). Сложности не надо придумывать там где их нет, на мой взгляд. Если есть желание ничего не делать и лениво гадать что будет с демоном из разряда 'на кого бог пошлет" то системд вполне подойдёт.
ясно. адепты баша
источник
16:20пожаловаться#9

a6

admin 666admin in DevOps Jobs - работа и аналитика
Посмотреть сам скрипт в течение 20 секунд?
источник
16:20пожаловаться#10

O

Onlinehead in DevOps Jobs - работа и аналитика
Вообще мне интересно, а из тех, кто говорит что "это круто просто неосилили" вообще хоть на половину понимают как это работает от начала до конца и как это чинить если что кроме "снести и заново накатить"? Ну то есть там тонна кода, просто мегатонна, я бы сказал. И по сути можно только верить, что оно все сделает как надо. Или становиться разрабом systemd :)
источник
16:21пожаловаться#11

a6

admin 666admin in DevOps Jobs - работа и аналитика
Dmitry Sergeev
ясно. адепты баша
Адепты здравого смысла. Если мне удобнее будет системд - будет системд, если удобнее sysvinit или rc init будут они
источник
16:21пожаловаться#12

DS

Dmitry Sergeev in DevOps Jobs - работа и аналитика
admin 666admin
Посмотреть сам скрипт в течение 20 секунд?
ммм 20 секунд. Скрипт на 3К строк и миллион функций из библиотеки LSB
источник
16:21пожаловаться#13

DS

Dmitry Sergeev in DevOps Jobs - работа и аналитика
admin 666admin
Адепты здравого смысла. Если мне удобнее будет системд - будет системд, если удобнее sysvinit или rc init будут они
bash это не здравый смысл
источник
16:22пожаловаться#14

a6

admin 666admin in DevOps Jobs - работа и аналитика
А зачем Вы такие скрипты используете в 3к строк на баше?
источник
16:22пожаловаться#15

AK

Andrey Kartashov in DevOps Jobs - работа и аналитика
Onlinehead
Вообще мне интересно, а из тех, кто говорит что "это круто просто неосилили" вообще хоть на половину понимают как это работает от начала до конца и как это чинить если что кроме "снести и заново накатить"? Ну то есть там тонна кода, просто мегатонна, я бы сказал. И по сути можно только верить, что оно все сделает как надо. Или становиться разрабом systemd :)
Такие как вы пихают в код сырые селекты вместо использования орм
источник
16:22пожаловаться#16

AK

Andrey Kartashov in DevOps Jobs - работа и аналитика
Системд - это унифицированный фреймворк для сервисов
источник
16:22пожаловаться#17

O

Onlinehead in DevOps Jobs - работа и аналитика
Andrey Kartashov
Такие как вы пихают в код сырые селекты вместо использования орм
Нет, не пихают. Это потестировать можно. У вас есть вариант потестировать systemd?:)
источник
16:22пожаловаться#18

DS

Dmitry Sergeev in DevOps Jobs - работа и аналитика
admin 666admin
А зачем Вы такие скрипты используете в 3к строк на баше?
вы сами себе скрипты пишите для sys v init? Не берете готовые от мейнтейра пакета. Это интересно =)
То есть придумали себе работу, которая давно уже решена, конфигом на 20 строчек в systemd, в большистве случаев даже конфиг писать не надо, так как он уже есть от того же мейнтенера пакета
источник
16:23пожаловаться#19

O

Onlinehead in DevOps Jobs - работа и аналитика
Блин, я все таки напомню - нравится - пользуйтесь, никто не запрещает. Но и не запрещайте другим говорить что оно им не нравится.
источник
16:23пожаловаться#20