Одно - это реиплементация велосипеда в каждом языке программирования неконсистентным образом.
systemd - окончательно победившая система инициализации у окончательно победившей серверной ОС. Решает вопрос демонизации, контейнеризации, логов, активации, зависимостей, перезапуска и так далее, все что нужно для «service» в системе.
Вот когда-нибудь из линукса выкинут сигрупс и запилят резко что-то новое, а ты и системд превратитесь в тыкву. Потому что древние технологии запиливания демонов уже утеряны!
systemd - окончательно победившая система инициализации у окончательно победившей серверной ОС. Решает вопрос демонизации, контейнеризации, логов, активации, зависимостей, перезапуска и так далее, все что нужно для «service» в системе.
Хорошо набросил. Полон тред криков о каких-то багах Шредингера. Если что я не собираюсь переубеждать. Я только сказал как оно реально есть. Хотите - возитесь со старьем, переписывайте код с PID файлом в сотый раз и делайте все свои баш-приседания.
баш там в виде отдельного скрипта который решает уникальность запуска через PIDFILE. я его по сто раз не переписываю, оно уже есть. но совсем по человечески вызывать fork()/daemon() из самого демона.
но совсем по человечески вызывать fork()/daemon() из самого демона.
Nope. По человечески - оставить в покое свое приложение, сделать его обычным консольным приложением. А потом заставить нормальную систему инициализации сделать все за тебя со стороны. Хоть systemd, хоть docker, хоть Kubernetes, в зависимости от того где и как оно должно работать
логи теряются только при дефолтных настрйоках и если демон много срёт. Это сделано от засирания общего лога сраньём отдельно взятого демона, и чтоб на диске место не закончилось.
Можно регулировать потерю логов как на общесистемном уровне, так и для отдельного сервиса.
Для этого в конфиге аж две опции есть: максимальный размер базы логов, минимальное количество свободного места на диске. При достижении лимита начинают удаляться самые старые записи.
RateLimitIntervalSec=, RateLimitBurst=¶
Configures the rate limiting that is applied to all messages generated on the system. If, in the time interval defined by RateLimitIntervalSec=, more messages than specified in RateLimitBurst= are logged by a service, all further messages within the interval are dropped until the interval is over. A message about the number of dropped messages is generated. This rate limiting is applied per-service, so that two services which log do not interfere with each other's limits. Defaults to 10000 messages in 30s.
Там байткод некошерный. Чтобы был кошерный нужно пострадать с оригинальным черезжопным ерлангом. Православные диды вон на асме писали, не доверяли компиляторам. Всем известно, что идеальный код возможен только если изрядно попотеть.
Все равно сферические 7 лет в вакууме ничего не дают. Там фичи разрабатываются каждый день. В компилятор фортрана можно просто взять и с утра вкатать баг прямо в компилятор и не заметить. И даже через 3 месяца не заметить, стрельнет только у тебя. Это просто параноя которая ничем не измеряется. Нельзя сказать когда что-то абсолютно надежно из-за того что оно пахнет от старости. Правильный подход - доверяться тестам, доверяться разному QA на environments приближенных к продакшну, доверяться мониторингу, системам оповещения, статистическим тестам разницы между версиями. Система - цельный продукт, и ты тестируешь и свой код и рантайм на котором он работает вместе. Баг там или там - будет найден. Пускай хотя бы команда Elixir была замечена в халатном отношении к багам, допустим у них были бы проблемы с процессами и отношением. Тогда да, а так «молодые еще» - это спекуляция.
Десятилетиями его тестировали, а новый баг вкатят сегодня. И раз ты молишься на его святость безгрешный ерланг, то не протестишь свой докер конйтенер нормально где твой софт и OTP одновременно работают. Я говорю что нужно тестировать финальный продукт, как там все работает вместе, что бы в нем ни было, хоть мощи Николая Угодника
Если очень хочется сделать это именно на го. Библиотека, которая вроде как решает эту задачу. https://github.com/sevlyar/go-daemon
Либо писать в домашнюю директорию пустой файл. При запуске проверять его наличие, а при завершении работы удалять. Логи писать в append only режиме в файл «my-cool-program.log»
Но если хочется сделать профессионально — используй systemd или другие похожие системы. Там надёжность выше и есть полезные фичи есть (например перезапуск при падении). И тебе не придётся руками поддерживать в коде ещё и систему демонизации, логирования и т.п.
С демонизацией и созданием пид-файлов отлично справляется start-stop-daemon, а так же «юзерские» супервизоры процессов. Нет никакой нужды реализовывать это в каждом демоне.
Одним маленьким параметром rc_bg=YES консольная тулза привращается в демона, стартует при буте, и само следит за тем, что бы не падало и более одного раза не запускалось.
Про всякие OpenRC и systemd даже говорить не приходится – всё это они тоже умеют из коробки.