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

ну он же exit code генерит

Рестартом? Тогда возникнет резонный вопрос: а на кой хрен ваш эрланг с его объёмом библиотек против Go, если ради мелкого изменения надо рестартить.

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

Т.е. управление по апи напрямую связано с проблематикой реконфигурирования на лету.

А application environment и супервизоры этому сопротивляются

динамические параметры в супервизор периодических хочется подсунуть да

ну да, их смену.

Не держать конфигурацию в спеках супервизора? Child может сам env'ы читать же

надо чтобы стртовал процесс с динамическим конфигом а рестартовал с тем что стартовал

это давно просится в супервизор. Какоето разделение старта от рестарта

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

# systemctl start flussonic
Job for flussonic.service failed because the control process exited with error code. See "systemctl status flussonic.service" and "journalctl -xe" for details.

— алё, поддержка, ничего не работает!
— давайте посмотрим в логи
— а там нет ничего:

flussonic.service - Flussonic streaming server
   Loaded: loaded (/lib/systemd/system/flussonic.service; enabled; vendor preset: enabled)
   Active: activating (start) since Wed 2020-09-02 17:10:46 CEST; 14s ago
  Process: 15836 ExecStartPre=/opt/flussonic/contrib/validate_config.erl (code=exited, status=0/SUCCESS)

и вот где-то здесь бывает то 0, то не н0

> и дальше возникает вопрос: а что делать, если третий процесс по цепочке упал, а первые два уже переконфигурировались.
ну так он рестартанётся и прочитает в init/1 новый конфиг

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

Думаю, что при такой постановке вопроса ответ очевиден =)

нууу... да

не вижу прям огромной проблемы в этом, но ок, принято

а вот то, что в systemd нельзя отдать какой-то текстовый reason — это тоже плохо, да. Ну и проблема не только конфигов касается кстати

ну тут, судя по всему,
намечается шаблон с двухфазным стартом,
который первым использовал
cuttlefish , а теперь повторяет
elixir в своих релизах,
первый старт с sys.config,
"человеческий конфиг"
мержится в sys.config,
exit и второй старт с смерженым конфигом.

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

задачу наверно можно свести к автоматически обновляемому env при изменении заданого конфига

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

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

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