демонизация в golang

Никак. Там с этим проблема. По крайне мере, была.

Штатными средствами, в принципе можно, но лучше не надо. Треды не очень дружат с форком. К тому же оно сильно платформо-зависимо.

• https://github.com/golang/go/issues/227
• https://github.com/sevlyar/go-daemon

Вопрос: зачем оно тебе?

Так же как и не в Go

https://www.freedesktop.org/software/systemd/man/systemd.service.html

Перестаньте писать уже это говно в коде.

В баге о поддержке этого в Go вот комментарий почему баг закрыли

https://github.com/golang/go/issues/227#issuecomment-254735160

Шо то говно, шо то

Вопрос: зачем оно тебе?

для того чтобы был демон. сейчас оно рулится скриптом на bash который PIDFILE поддерживает - хочу уйти от этого

Нет.

Одно - это реиплементация велосипеда в каждом языке программирования неконсистентным образом.

systemd - окончательно победившая система инициализации у окончательно победившей серверной ОС. Решает вопрос демонизации, контейнеризации, логов, активации, зависимостей, перезапуска и так далее, все что нужно для «service» в системе.

Перестаньте писать уже это говно в коде.

типа SYSV уже нет? нет уж будем писать так чтобы везде работало, а не только в systemd

типа SYSV уже нет?

Да, уже нет и быть не должно. Если у вас есть, то это сильно устаревший сервер.

Да, уже нет и быть не должно.

да вы батенька фашист. а мы за разнообразие и свободу выбора

systemd. Если его нет, то supervisord.

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

Решает вопрос демонизации, контейнеризации, логов, активации, зависимостей, перезапуска и так далее, все что нужно для «service» в системе.

Оно перестало эти логи терять, чтобы быть «решением»?

Как пять лет назад теряло, так и сейчас. Как пять лет назад говорили «пофиксим скоро», так и сейчас ― «скоро пофиксим».

А это говно все еще теряет логи. Ну и кому это «решение» нужно?

systemd - окончательно победившая система инициализации у окончательно победившей серверной ОС. Решает вопрос демонизации, контейнеризации, логов, активации, зависимостей, перезапуска и так далее, все что нужно для «service» в системе.

Говори за себя.

Ты что-то делаешь очень не так.

Рукоблудная демонизация, без должного сопутствующего логирования, коту под хвост.

Этим давным давно занимаются системы инициализации и контейнеры.

Хорошо набросил. Полон тред криков о каких-то багах Шредингера. Если что я не собираюсь переубеждать. Я только сказал как оно реально есть. Хотите - возитесь со старьем, переписывайте код с PID файлом в сотый раз и делайте все свои баш-приседания.

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

баш там в виде отдельного скрипта который решает уникальность запуска через PIDFILE. я его по сто раз не переписываю, оно уже есть. но совсем по человечески вызывать fork()/daemon() из самого демона.

Без ротации, я так понимаю?

Ради бога, чем бы дитя не тешилось. И закат солнца в ручную бывает милым.

Но всё же, на всё это есть уже готовые, проверенные решения.

Тч ещё раз вопрос: зачем огород городиш?

но совсем по человечески вызывать fork()/daemon() из самого демона.

Nope. По человечески - оставить в покое свое приложение, сделать его обычным консольным приложением. А потом заставить нормальную систему инициализации сделать все за тебя со стороны. Хоть systemd, хоть docker, хоть Kubernetes, в зависимости от того где и как оно должно работать

Ты вообще ерундой занимаешься! Пиши динамические опердени на Erlang, не приседая со штангой!

Erlang

Не модно. Elixir говорят правильно вейпать на гироскутере

Elixir

Зачем это говно? Erlang хорош особенно с OTP, в здравом уме в проде elixir не будут использовать.

Ну оно же вроде со всем вместе работает, и с этим OTP. Или нет? Просто синтаксис лучше. И вебфреймворк для ленивых есть

Elexir сырой для прода, erlang супер стабильный.

вот комментарий почему баг закрыли

Упорото. Как и всё остальное в го

Elexir сырой для прода

Пруфца бы.

Erlang - 1986

Elixir - 2012

systemd – … система инициализации

Не ори. Министерство правды только-только закончило убеждать критикующих жирность что системд – не система инициализации.

Как раз таки такой способ запуска уже не кошерен, так как на самом деле состоит из костылей. И пид файлы эти - тоже костыли

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

Запусти свою программулину через start-stop-daemon с ключом -b

/thread

Оно перестало эти логи терять

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

чтоб на диске место не закончилось

Для этого в конфиге аж две опции есть: максимальный размер базы логов, минимальное количество свободного места на диске. При достижении лимита начинают удаляться самые старые записи.

Оно перестало эти логи терять, чтобы быть «решением»?

https://www.freedesktop.org/software/systemd/man/journald.conf.html

set

RateLimitIntervalSec=100 RateLimitBurst=9999999999

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.

При достижении лимита начинают удаляться самые старые записи.

Не в этом дело. Если один демо активно срёт, то ограничивается логирование одного демона, чтоб он не вытеснил все другие логи.

1. start-stop-daemon
2. systemd

Обычная параноя. На работке ты тоже 7 лет ждешь прежде чем в прод задеплоить?

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

Мои ошибки это одно, а косяки стандартной библиотеки и рантайм - это другое.

Все равно сферические 7 лет в вакууме ничего не дают. Там фичи разрабатываются каждый день. В компилятор фортрана можно просто взять и с утра вкатать баг прямо в компилятор и не заметить. И даже через 3 месяца не заметить, стрельнет только у тебя. Это просто параноя которая ничем не измеряется. Нельзя сказать когда что-то абсолютно надежно из-за того что оно пахнет от старости. Правильный подход - доверяться тестам, доверяться разному QA на environments приближенных к продакшну, доверяться мониторингу, системам оповещения, статистическим тестам разницы между версиями. Система - цельный продукт, и ты тестируешь и свой код и рантайм на котором он работает вместе. Баг там или там - будет найден. Пускай хотя бы команда Elixir была замечена в халатном отношении к багам, допустим у них были бы проблемы с процессами и отношением. Тогда да, а так «молодые еще» - это спекуляция.

А зачем? Это всё systemd может за тебя сделать.

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

Ты сам себе противоречишь, erlang используется десятилетиями в больших продакшен проектах и он как раз оттестирован и отшлифован.

А зачем? Это всё systemd может за тебя сделать.

Он отстуник с комплексами.

Десятилетиями его тестировали, а новый баг вкатят сегодня. И раз ты молишься на его святость безгрешный ерланг, то не протестишь свой докер конйтенер нормально где твой софт и OTP одновременно работают. Я говорю что нужно тестировать финальный продукт, как там все работает вместе, что бы в нем ни было, хоть мощи Николая Угодника

И раз ты молишься на его святость безгрешный ерланг

Erlang - говно, но уже окаменелое, а Elixir - попахивает.

Если очень хочется сделать это именно на го. Библиотека, которая вроде как решает эту задачу. https://github.com/sevlyar/go-daemon Либо писать в домашнюю директорию пустой файл. При запуске проверять его наличие, а при завершении работы удалять. Логи писать в append only режиме в файл «my-cool-program.log»

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

типа SYSV уже нет

С демонизацией и созданием пид-файлов отлично справляется start-stop-daemon, а так же «юзерские» супервизоры процессов. Нет никакой нужды реализовывать это в каждом демоне.

демон обслуживающий железку с которым взаимодействует сторонняя система. докер сюда впихнуть предлагаете?

Ну оно же не в вакууме у тебя там работает? Хоть какая-то система инициализации есть?

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

#!/bin/sh

daemon="/usr/local/bin/blog"
daemon_user=www

. /etc/rc.d/rc.subr

rc_bg=YES
rc_reload=NO

rc_cmd $1

Одним маленьким параметром rc_bg=YES консольная тулза привращается в демона, стартует при буте, и само следит за тем, что бы не падало и более одного раза не запускалось.

Про всякие OpenRC и systemd даже говорить не приходится – всё это они тоже умеют из коробки.

Извините за оффтоп. Вы там с мускулом ковыряетесь, а автор треда отключил комментирование для анонов. Передайте ему, что причина в auth_socket.