Golang daemon - История изменений

imported>Vix в 01:40, 27 сентября 2020

2020-09-27T01:40:49Z

← Предыдущая версия		Версия от 04:40, 27 сентября 2020
Строка 12:		Строка 12:

	Отсутствие в стандартном пакете syscall чистого fork меня не остановило и даже не вызвало никаких подозрений. Я просто сделал примерно так (упрощено):		Отсутствие в стандартном пакете syscall чистого fork меня не остановило и даже не вызвало никаких подозрений. Я просто сделал примерно так (упрощено):
	<~~code~~>		<syntaxhighlight lang="shell" line='line'>
	ret, _, err := syscall.Syscall(syscall.SYS_FORK, 0, 0, 0)		ret, _, err := syscall.Syscall(syscall.SYS_FORK, 0, 0, 0)
	if err != 0 {		if err != 0 {
Строка 21:		Строка 21:
	os.Exit(0)		os.Exit(0)
	}		}
	</~~code~~>		</syntaxhighlight>
	Реализовав все пункты, запустив демона и полюбовавшись выводом команд ps -eafw и		Реализовав все пункты, запустив демона и полюбовавшись выводом команд
	lsof -p , я подумал, что пора бы переходить к реализации обработки системных сигналов.		ps -eafw и
			lsof -p , я подумал, что пора бы переходить к реализации обработки системных сигналов.


	Добавление обработки сигналов поначалу мне казалось пустяковой вещью, ведь в Go есть стандартный пакет os/signal. Но когда я проделал это работу, мой демон наотрез отказывался получать эти самые сигналы. Причем если я убирал fork, обработка сигналов работала отлично. Сей факт меня весьма огорчил. Тогда я начал искать информацию в сети и, почитав code.google.com/p/go/issues/detail?id=227, огорчился еще больше. Собственно вывод был прост: В Go нельзя использовать fork, т.к. дочерний процесс не наследует потоки, а это означает, что все горутины (goroutines), заблокированные системными вызовами в потоках, отличных от текущего, отваливаются.		Добавление обработки сигналов поначалу мне казалось пустяковой вещью, ведь в Go есть стандартный пакет os/signal. Но когда я проделал это работу, мой демон наотрез отказывался получать эти самые сигналы. Причем если я убирал fork, обработка сигналов работала отлично. Сей факт меня весьма огорчил. Тогда я начал искать информацию в сети и, почитав code.google.com/p/go/issues/detail?id=227, огорчился еще больше. Собственно вывод был прост: В Go нельзя использовать fork, т.к. дочерний процесс не наследует потоки, а это означает, что все горутины (goroutines), заблокированные системными вызовами в потоках, отличных от текущего, отваливаются.
Строка 33:		Строка 32:
	Тогда я оставил в покое обработку сигналов и начал экспериментировать с горутинами. Оказалось, что после вызова fork они прекрасно запускаются и работают в дочернем процессе. Открыв и почитав исходный код пакета os/signal, я понял, что все дело в этом коде:		Тогда я оставил в покое обработку сигналов и начал экспериментировать с горутинами. Оказалось, что после вызова fork они прекрасно запускаются и работают в дочернем процессе. Открыв и почитав исходный код пакета os/signal, я понял, что все дело в этом коде:

	<~~code~~>		<syntaxhighlight lang="shell" line='line'>
	func init() {		func init() {
	signal_enable(0) // first call - initialize		signal_enable(0) // first call - initialize
	go loop()		go loop()
	}		}
	</~~code~~>		</syntaxhighlight>
	Здесь, в функции инициализации пакета, функция loop() запускается в качестве отдельной горутины. Это происходит еще до вызова функции main(). Функция loop() в цикле запрашивает очередной системный вызов и передает его назначенным обработчикам. Получается, что при вызове fork, перестает функционировать loop(). Но, горутины прекрасно запускаются и работаю после вызова fork. Значит надо делать вызов этой функции init() после вызова fork, решил я.		Здесь, в функции инициализации пакета, функция loop() запускается в качестве отдельной горутины. Это происходит еще до вызова функции main(). Функция loop() в цикле запрашивает очередной системный вызов и передает его назначенным обработчикам. Получается, что при вызове fork, перестает функционировать loop(). Но, горутины прекрасно запускаются и работаю после вызова fork. Значит надо делать вызов этой функции init() после вызова fork, решил я.

Строка 46:		Строка 45:

	В результате я написал примерно такой код:		В результате я написал примерно такой код:
	<~~code~~>		<syntaxhighlight lang="shell" line='line'>
	const (		const (
	envVarName = "_GO_DAEMON"		envVarName = "_GO_DAEMON"
Строка 77:		Строка 76:
	return os.Getenv(envVarName) == envVarValue		return os.Getenv(envVarName) == envVarValue
	}		}
	</~~code~~>		</syntaxhighlight>
	Приведенный код прекрасно работает со стандартной библиотекой. Правда здесь используется пакет os/exec - высокоуровневая обертка над StartProcess.		Приведенный код прекрасно работает со стандартной библиотекой. Правда здесь используется пакет os/exec - высокоуровневая обертка над StartProcess.

imported>Vix: Новая страница: «Около года назад мне понадобилось написать linux демона, реализующего небольшой сетевой с...»

2020-09-27T01:37:34Z

Новая страница: «Около года назад мне понадобилось написать linux демона, реализующего небольшой сетевой с...»

Новая страница

Около года назад мне понадобилось написать linux демона, реализующего небольшой сетевой сервис. В то время я активно изучал Go и мне очень нравился этот язык, поэтому взвесив все за и против я решил реализовать задачу на нем. К тому же, Go уже был стабильным и имел версию 1.0.1.

О том, с какими подводными камнями мне пришлось столкнуться, читайте под катом, но сразу оговорюсь: я буду описывать только тонкости реализации демона на Go. Если вы слабо представляете что такое «демон» или как демонизируется процесс, сначала стоит об этом почитать, поискав в гугле или на хабре «linux daemon» или пройдясь по списку ссылок в конце статьи.

Но вернемся к демонам. Сначала я решил действовать классически:
Порождение дочернего процесса и завершение родительского (системный вызов fork);
Далее в дочернем процессе:
Установка маски для прав доступа на вновь создаваемые файлы (системный вызов umask);
Создание нового сеанса, отключение от терминала (системный вызов setsid);
Смена рабочей директории на корневую (системный вызов chdir);
Перенаправление дескрипторов потоков стандартного ввода/вывода на /dev/null.

Отсутствие в стандартном пакете syscall чистого fork меня не остановило и даже не вызвало никаких подозрений. Я просто сделал примерно так (упрощено):
<code>
ret, _, err := syscall.Syscall(syscall.SYS_FORK, 0, 0, 0)
if err != 0 {
os.Exit(2)
}
if ret > 0 {
// родительский процесс
os.Exit(0)
}
</code>
Реализовав все пункты, запустив демона и полюбовавшись выводом команд ps -eafw и
lsof -p , я подумал, что пора бы переходить к реализации обработки системных сигналов.

Добавление обработки сигналов поначалу мне казалось пустяковой вещью, ведь в Go есть стандартный пакет os/signal. Но когда я проделал это работу, мой демон наотрез отказывался получать эти самые сигналы. Причем если я убирал fork, обработка сигналов работала отлично. Сей факт меня весьма огорчил. Тогда я начал искать информацию в сети и, почитав code.google.com/p/go/issues/detail?id=227, огорчился еще больше. Собственно вывод был прост: В Go нельзя использовать fork, т.к. дочерний процесс не наследует потоки, а это означает, что все горутины (goroutines), заблокированные системными вызовами в потоках, отличных от текущего, отваливаются.

Тогда я оставил в покое обработку сигналов и начал экспериментировать с горутинами. Оказалось, что после вызова fork они прекрасно запускаются и работают в дочернем процессе. Открыв и почитав исходный код пакета os/signal, я понял, что все дело в этом коде:

<code>
func init() {
signal_enable(0) // first call - initialize
go loop()
}
</code>
Здесь, в функции инициализации пакета, функция loop() запускается в качестве отдельной горутины. Это происходит еще до вызова функции main(). Функция loop() в цикле запрашивает очередной системный вызов и передает его назначенным обработчикам. Получается, что при вызове fork, перестает функционировать loop(). Но, горутины прекрасно запускаются и работаю после вызова fork. Значит надо делать вызов этой функции init() после вызова fork, решил я.

Я полностью скопировал код пакета os/signal, элементарно переименовал функцию init() в Init() и добавил ее вызов после fork. После чего обработка сигналов заработала ценой отказа от стандартной библиотеки и путем создания велосипеда.

Спустя какое-то время я пришел к выводу, что мой демон состоит из: костыль - одна штука и велосипед - одна штука. А костыль от того, что если еще какому-то пакету захочется создать горутину в функции инициализации, то пакет откажется корректно работать в демоне. Поэтому я решил поискать немного другой путь, и копание в стандартной библиотеке натолкнуло меня на мысль использовать функцию StartProcess. Поковыряв исходники, я понял, что эта функция последовательно делает системные вызовы fork и exec безопасным образом. По сути мы ничего не теряем, только дочерний процесс как бы перезапускается заново, а значит, надо как-то сообщать ему об этом. Чтобы он мог спокойно закончить демонизацию, проведя системные вызовы далее по списку. Сначала я использовал передачу аргументов командной строки, а потом решил для уведомления дочернего процесса передавать переменную окружения _GO_DAEMON=1.

В результате я написал примерно такой код:
<code>
const (
envVarName = "_GO_DAEMON"
envVarValue = "1"
)
func Reborn(umask uint32, workDir string) (err error) {
if !WasReborn() {
var path string
if path, err = filepath.Abs(os.Args[0]); err != nil {
return
}
cmd := exec.Command(path, os.Args[1:]...)
envVar := fmt.Sprintf("%s=%s", envVarName, envVarValue)
cmd.Env = append(os.Environ(), envVar)
if err = cmd.Start(); err != nil {
return
}
os.Exit(0)
}
syscall.Umask(int(umask))
if len(workDir) == 0 {
if err = os.Chdir(workDir); err != nil {
return
}
}
_, err = syscall.Setsid()
return
}
func WasReborn() bool {
return os.Getenv(envVarName) == envVarValue
}
</code>
Приведенный код прекрасно работает со стандартной библиотекой. Правда здесь используется пакет os/exec - высокоуровневая обертка над StartProcess.

Надо четко понимать, что здесь, в отличии от классического метода демонизации, весь ваш код, выполненный до вызова Reborn(), также будет выполнен в дочернем процессе. Если вы не хотите этого - следует использовать функцию WasReborn(). А так же дочерний процесс не наследует дескрипторы файлов (возможно, я добавлю это позже), поэтому родительский процесс должен закрывать все файлы до вызова Reborn(), а дочерний должен после вызова Reborn() перенаправлять стандартные потоки вывода в лог (также это позволит узнать что же произошло при неожиданном panic()), а ввода - на /dev/null.

После того, как мне пришлось написать еще пару демонов, я решил оформить функции демонизации в виде пакета и выложить на github: go-daemon. Так же в пакете доступны функции создания и блокировки pid-файлов и перенаправления потоков. Там же находится пример реализации простейшего демона на Go. Надеюсь этот материал будет кому-то полезен.

'''ИСТОЧНИК:'''
<hr>
* [https://habr.com/ru/post/187668/ Golang daemon]

'''Дополнительно:'''
<hr>
* [https://github.com/skx/go.vm go.vm]
* [https://gobyexample.ru/execing-processes.html Go в примерах: Выполнение процессов (Exec'ing Processes)]
* [https://askdev.ru/q/golang-exec-process-i-otkazatsya-ot-nego-377941/ Golang exec process и отказаться от него]