LINUX.ORG.RU

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

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

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 2)

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

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

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

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

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

vertexua ★★★★☆ ()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от moot

Нет.

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

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

vertexua ★★★★☆ ()
Ответ на: комментарий от vertexua

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

moot ★★★★ ()
Ответ на: комментарий от vertexua

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

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

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

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

anonymous ()
Ответ на: комментарий от vertexua

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

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

LongLiveUbuntu ★★★★★ ()
Ответ на: комментарий от quester

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

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

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

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 1)

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

vertexua ★★★★☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

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

quester ★★ ()
Ответ на: комментарий от quester

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

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

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

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

beastie ★★★★★ ()
Ответ на: комментарий от quester

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

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

vertexua ★★★★☆ ()
Ответ на: комментарий от AUX

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

vertexua ★★★★☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

Radjah ★★★★★ ()
Ответ на: комментарий от anonymous

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

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.

anonymous ()
Ответ на: комментарий от Radjah

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

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

anonymous ()
Ответ на: комментарий от vertexua

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

anonymous ()
Ответ на: комментарий от AUX

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

vertexua ★★★★☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

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

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

AUX ★★★ ()
Последнее исправление: AUX (всего исправлений: 1)
Ответ на: комментарий от AUX

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

vertexua ★★★★☆ ()

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

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

brualan ()
Ответ на: комментарий от quester

типа SYSV уже нет

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

annulen ★★★★★ ()
Ответ на: комментарий от quester

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

Ну вот тебе пример инит скрипта моего зачахлого бложика (да, тоже на 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 даже говорить не приходится – всё это они тоже умеют из коробки.

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 3)