это когда данные не теряешь на db2 + zfs

Коллеги, давайте не репостить профунктор-оптикс в чат

тем более без репоста

С репостом оно ещё хуже

Какой еще профунктор оптикс? Никогда не слышал!

Коллеги, а в дб2 можно женкинсом деплоить.?

Нет, только scp

Плохой продукт

Его нужно деплоить один раз в жизни, он же не развивается

Раз в жизни светлячков))

Доброе утро. Есть вопрос по опции restart=always у докер контейнеров:
у нас есть пачка контейнеров, у которых выставлена данная опция.
Внутри контейнеров работает софт на C++, который периодически может падать
(segmentation fault). Сами контейнеры при этом останавливаются с таким кодом:

docker ps -a | grep -i exit
20..   registry.ru/ssp:5                "/usr/local/bin/dock…"   32 hours ago   Exited (139) 2 hours ago                            ssp1
...

Само падение не страшно, если докер потом обратно поднимет контейнеры (на одном хосте с десяток таких контейнеров плюс самих хостов с десяток).
Почти всегда так и происходит, но иногда, не понятно почему, докер контейнеры обратно не поднимает. Т.е. в контейнерах на хосте массово (в пределах пары минут) происходит segfault, контейнеры стопнулись и докер обратно их не пытается поднимать.

Логи событий по одному из контейнеров:

 docker events --since "2021-05-01"  --filter container=ssp1
...
2021-05-21T19:32:57.554949557+03:00 container die ... exitCode=139, image=registry.ru/ssp:5
2021-05-21T21:57:02.237286190+03:00 container start  ... image=registry.ru/ssp:5
2021-05-21T23:34:24.346921893+03:00 container die ... exitCode=139, image=registry.ru/ssp:5
2021-05-21T23:34:26.727113672+03:00 container start ... image=registry.ru/ssp:5
...
2021-05-23T14:35:05.392302401+03:00 container die ...
2021-05-23T22:15:24.825501692+03:00 container start ...

В 19:32 было падение, в 21:57 руками его подняли. В 23:34 было опять падение, но здесь докер уже сам запустил контейнер.
В 14:35 опять упал, в 22:15 опять подняли руками.

docker inspect ssp1 | jq '.[0].HostConfig.RestartPolicy'
{
 "Name": "always",
 "MaximumRetryCount": 0
}

Как такое полечить/поправить?

оркестратора нету (k8s), хотелось бы поправить ситуацию нативными средствами

Про нужный канал ты в курсе

Всем хорошего дня!
Вопрос по gitlab ci.
Есть пайплайн надо сделать так чтобы джоба запускалась в зависимости от результата предыдущей.
Пример: есть стейдж линт, есть стейдж билд. Если на линте все окей, то билд должен запускаться автоматически. Если линт упал, то билд должен запускаться автоматически.

Сейчас в билде сделал две джобы - одну on_success, другую manual. Но так не работает если делать линт allow_failure: true, то запускается автоматический билд, а если поставить allow_failure:false, то пайплайн просто падает на линте и не даёт запускать в ручную билд.

Есть какое то решение для такой ситуации?

а смысл игнорировать линт?

смысл тогда в линте

allow_failure: true должен был помочь

так он и пишет что запускается, а потом сетует на то что в allow_failure: false не работает, что логично

но это не отменяет вопрос - нафига тогда линт если не зависимо от его результата надо билдить