Golang - 콘솔 응용 프로그램을 Linux 데몬 서비스를 지원하도록 변경
지난 글에 이어,
Golang - 콘솔 응용 프로그램을 NT 서비스를 지원하도록 변경
; https://www.sysnet.pe.kr/2/0/13854
이번에는 Linux의 데몬으로 실행되도록 변경해보겠습니다.
개인적으로, SCM과의 상호작용을 고려해야 하는 Windows NT 서비스가 Linux의 데몬보다 복잡한 구조로 만들어졌다고 생각했는데요, 하지만 "
리눅스 API의 모든 것, 기초 리눅스 API"의 내용을 보면 그에 못지 않은 것 같습니다. ^^ (linux daemonize로 검색해 보시면 관련 자료가 많이 나옵니다.)
물론, (가령 fork를 이용한 다중 처리 구조가 아니라면) 단순하게 최소한의 절차만 따르는 것도 가능합니다. 게다가 프레임워크에 따라서는 signal 처리에 대한 default handler를 제공하는 경우도 있어 좀 더 간단해질 수 있는데요, 실제로
예전에 닷넷으로 만든 데몬은 별도의 처리 없이 systemctl의 등록만으로 잘 동작했습니다.
그렇다면 Go 언어는 어떨까요? 단순한 설명보다 코드를 곁들여 직접 구현하면서 보는 것이 좋겠지요. ^^
package main
import (
"bufio"
"log"
"os"
"time"
)
func main() {
go doMyWork()
log.Println("Press any key to exit...")
input := bufio.NewScanner(os.Stdin)
input.Scan()
log.Println("Exited.")
}
func doMyWork() {
tick := time.Tick(1 * time.Second)
for {
select {
case <-tick:
log.Println("Tick Handled (Console)...!")
}
}
}
일단 위의 상태로도 다음과 같은 내용의 등록 파일만 있다면 systemctl에 데몬으로 등록은 가능합니다.
$ cat /etc/systemd/system/go-sample-daemon.service
[Unit]
Description = go-sample-daemon
[Service]
WorkingDirectory = /mnt/c/temp/sample_daemon
ExecStart = /mnt/c/temp/sample_daemon/go-sample-daemon
SyslogIdentifier = go-sample-daemon
KillMode = process
[Install]
WantedBy = multi-system
하지만, 윈도우와 달리 *NIX의 데몬은 콘솔이 분리된 상태이므로 Stdin으로부터 입력을 받는 Scan 함수가 곧바로 제어를 반환하게 돼, 결국 위의 경우에는 그대로 프로그램을 종료하게 되는 효과를 갖습니다.
$ sudo systemctl start go-sample-daemon
$ systemctl status go-sample-daemon
● go-sample-daemon.service - go-sample-daemon
Loaded: loaded (/etc/systemd/system/go-sample-daemon.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Dec 27 21:23:52 testpc systemd[1]: Started go-sample-daemon running on testnix.
Dec 27 21:23:52 testpc go-sample-daemon[2793452]: 2024/12/27 21:23:52 Press any key to exit...
Dec 27 21:23:52 testpc go-sample-daemon[2793452]: 2024/12/27 21:23:52 Exited.
Dec 27 21:23:52 testpc systemd[1]: go-sample-daemon.service: Succeeded.
따라서, 이런 경우에는 데몬이 종료되지 않도록 계속 붙잡아 둘 다른 방법을 사용해야 하는데요, 가장 만만한 것이, 내부적으로 configuration을 재설정하도록 (관습적으로) 할당된 SIGHUP 신호를 기다리는 방법이 있습니다.
func main() {
go doMyWork()
hupSignal := make(chan os.Signal)
signal.Notify(hupSignal, syscall.SIGHUP)
for {
select {
case <-hupSignal:
log.Println("HUP signaled!")
break
}
}
log.Println("Exited.")
}
이후 다시 systemctl로 데몬을 테스트하면,
$ sudo systemctl start go-sample-daemon
$ sudo kill -s SIGHUP $(pgrep -f go-sample-daemon)
$ sudo systemctl stop go-sample-daemon
$ systemctl status go-sample-daemon
● go-sample-daemon.service - go-sample-daemon
Loaded: loaded (/etc/systemd/system/go-sample-daemon.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Jan 06 21:54:19 testpc systemd[1]: go-sample-daemon.service: Succeeded.
Jan 06 21:55:06 testpc systemd[1]: Started go-sample-daemon.
Jan 06 21:55:07 testpc go-sample-daemon[1751085]: 2025/01/06 21:55:07 Tick Handled (Console)...!
Jan 06 21:55:08 testpc go-sample-daemon[1751085]: 2025/01/06 21:55:08 HUP signaled!
Jan 06 21:55:08 testpc go-sample-daemon[1751085]: 2025/01/06 21:55:08 Tick Handled (Console)...!
Jan 06 21:55:09 testpc go-sample-daemon[1751085]: 2025/01/06 21:55:09 Tick Handled (Console)...!
Jan 06 21:55:10 testpc go-sample-daemon[1751085]: 2025/01/06 21:55:10 Tick Handled (Console)...!
Jan 06 21:55:11 testpc systemd[1]: Stopping go-sample-daemon...
Jan 06 21:55:11 testpc systemd[1]: go-sample-daemon.service: Succeeded.
Jan 06 21:55:11 testpc systemd[1]: Stopped go-sample-daemon.
보는 바와 같이 "kill -s SIGHUP"에 의해 HUP 시그널을 받았고, 이후 "systemctl stop"으로 데몬이 종료할 때까지 "Tick Handled (Console)" 출력도 정상적으로 동작했습니다. 참고로, SIGHUP이 데몬에서는 보통 reload 용도로 사용되긴 하지만 이것이 곧바로 "systemctl reload" 명령과 연동하지는 않습니다. 가령 위의 응용 프로그램에 대해 reload를 시도하면 이런 오류가 발생합니다.
$ sudo systemctl reload go-sample-daemon
Failed to reload go-sample-daemon.service: Job type reload is not applicable for unit go-sample-daemon.service.
reload 명령과 연계하려면 명시적으로 service 파일에 아래와 같은 설정을 추가해야 하는데요,
$ cat /etc/systemd/system/go-sample-daemon.service
...[생략]...
[Service]
...[생략]...
ExecReload=/bin/kill -HUP $MAINPID
...[생략]...
즉, reload 동작이 단순히 SIGHUP으로 제한된 것은 아니고 다양하게 연동할 수 있는 방법을 열어둔 것입니다.
기왕지사 데몬에 signal 처리를 해봤으니, 이번 기회에 "systemctl"의 "stop"과 "kill"의 차이점을 알아볼 텐데요, 기본적으로 systemctl kill, systemctl stop은 서비스로 SIGTERM을 보내기 때문에 다음과 같이 처리할 수 있습니다.
func main() {
go doMyWork()
hupSignal := make(chan os.Signal)
terminateSignal := make(chan os.Signal)
signal.Notify(hupSignal, syscall.SIGHUP)
signal.Notify(terminateSignal, syscall.SIGTERM)
for {
select {
case <-hupSignal:
log.Println("HUP signaled!")
break
case <-terminateSignal: // systemctl kill, systemctl stop
log.Println("TERM signaled!")
goto ExitProc // 또는, os.Exit(0)
}
}
ExitProc:
log.Println("Exited.")
}
이후 데몬을 시작하고, systemctl kill, systemctl stop 어떤 명령을 내려도 SIGTERM을 받는 것을 확인할 수 있습니다.
Jan 06 22:26:07 testpc systemd[1]: Started go-sample-daemon.
Jan 06 22:26:08 testpc go-sample-daemon[1767272]: 2025/01/06 22:26:08 Tick Handled (Console)...!
Jan 06 22:26:09 testpc go-sample-daemon[1767272]: 2025/01/06 22:26:09 HUP signaled!
Jan 06 22:26:09 testpc go-sample-daemon[1767272]: 2025/01/06 22:26:09 Tick Handled (Console)...!
Jan 06 22:26:10 testpc go-sample-daemon[1767272]: 2025/01/06 22:26:10 Tick Handled (Console)...!
Jan 06 22:26:11 testpc go-sample-daemon[1767272]: 2025/01/06 22:26:11 Tick Handled (Console)...!
Jan 06 22:26:12 testpc go-sample-daemon[1767272]: 2025/01/06 22:26:12 TERM signaled!
Jan 06 22:26:12 testpc go-sample-daemon[1767272]: 2025/01/06 22:26:12 Exited.
stop의 경우 kill과 다른 점이 있다면 service 파일에서 signal을 재설정할 수 있다는 점인데요,
...[생략]...
[Service]
...[생략]...
KillSignal = SIGINT # 개인적으로, KillSignal이 아닌 StopSignal이라고 했다면 더 좋았을 것 같다는 생각입니다. ^^;
...[생략]...
위와 같이 SIGINT로 교체한 경우라면 이제 다음과 같이 kill과 stop을 구분할 수 있습니다.
func main() {
go doMyWork()
hupSignal := make(chan os.Signal)
terminateSignal := make(chan os.Signal)
interruptSignal := make(chan os.Signal)
signal.Notify(hupSignal, syscall.SIGHUP)
signal.Notify(terminateSignal, syscall.SIGTERM)
signal.Notify(interruptSignal, syscall.SIGINT)
for {
select {
case <-hupSignal:
log.Println("HUP signaled!")
break
case <-terminateSignal: // systemctl kill
log.Println("TERM signaled!")
goto ExitProc
case <-interruptSignal: // systemctl stop (KillSignal = SIGINT)
log.Println("INT signaled!")
goto ExitProc
}
}
ExitProc:
log.Println("Exited.")
}
kill과 stop의 또 다른 결정적인 차이점은,
How does the systemd stop command actually work?
; https://stackoverflow.com/questions/42978358/how-does-the-systemd-stop-command-actually-work
"systemctl stop"의 경우 SIGTERM을 보내고 90초 동안 대기했다가 SIGKILL을 보내 강제 종료까지 이끌어낸다는 점입니다. (물론 "KillSignal = SIGINT"을 지정했다면 SIGINT를 보내고 90초 대기를 합니다.)
실제로 테스트를 이런 식으로 확인할 수 있습니다.
func main() {
go doMyWork()
hupSignal := make(chan os.Signal)
terminateSignal := make(chan os.Signal)
interruptSignal := make(chan os.Signal)
signal.Notify(hupSignal, syscall.SIGHUP)
signal.Notify(terminateSignal, syscall.SIGTERM)
signal.Notify(interruptSignal, syscall.SIGINT)
for {
select {
case <-hupSignal:
log.Println("HUP signaled!")
break
case <-terminateSignal: // systemctl kill
log.Println("TERM signaled!")
goto ExitProc
case <-interruptSignal: // systemctl stop (KillSignal = SIGINT)
log.Println("INT signaled!")
break // 일부러 (종료하지 않게) for 무한 루프를 돌도록 변경
// goto ExitProc
}
}
ExitProc:
log.Println("Exited.")
}
데몬을 시작하고, systemctl stop을 하면 아래와 같이 90초 동안 대기한 후에 SIGKILL을 보내 (강제) 종료시킵니다.
Jan 06 22:57:26 testpc go-sample-daemon[1779340]: 2025/01/06 22:57:26 INT signaled!
Jan 06 22:58:53 testpc systemd[1]: go-sample-daemon.service: State 'stop-sigterm' timed out. Killing.
Jan 06 22:58:53 testpc systemd[1]: go-sample-daemon.service: Killing process 1779340 (go-sample-daemo) with signal SIGKILL.
Jan 06 22:58:53 testpc systemd[1]: go-sample-daemon.service: Main process exited, code=killed, status=9/KILL
Jan 06 22:58:53 testpc systemd[1]: go-sample-daemon.service: Failed with result 'timeout'.
Jan 06 22:58:53 testpc systemd[1]: Stopped go-sample-daemon.
"systemctl stop"이 재미있는 점은, 위와 같이 서비스가 "Stopped" 될 때까지 제어를 반환하지 않는다는 점입니다. 즉, 단순히 해당 프로세스에 KillSignal을 보내고 끝나는 것이 아니라, 해당 프로세스가 종료될 때까지 대기하고 있다는 점입니다.
바로 이 점이 "systemctl kill"과의 차이점인데요, 가령 SIGTERM에 대해 응용 프로그램이 종료하지 않는 식으로 처리하는 경우,
func main() {
go doMyWork()
terminateSignal := make(chan os.Signal)
signal.Notify(terminateSignal, syscall.SIGTERM)
for {
select {
case <-terminateSignal: // systemctl kill
log.Println("TERM signaled!")
break // 일부러 (종료하지 않도록) for 무한 루프를 타도록 변경
// goto ExitProc
}
}
log.Println("Exited.")
}
위의 프로세스에 대해 systemctl kill을 하면 아래와 같이 로그는 남지만,
Jan 06 21:05:25 testpc go-sample-daemon[1782934]: 2025/01/06 21:05:25 TERM signaled!
프로세스는 여전히 (90초 이후에도) 실행 중인 상태로 남게 되고, systemctl은 바로 제어를 반환합니다. 즉, "systemctl kill"은 "kill"이라는 의미에서 벗어나 단순히 특정 시그널로서 SIGTERM을 보낸다는 정도로 이해하시면 됩니다.
참고로, Go 언어에서는 SIGKILL에 대한 핸들러는 등록해도 무시됩니다.
killSignal := make(chan os.Signal)
signal.Notify(killSignal, syscall.SIGKILL)
for {
select {
// ...[생략]...
case <-killSignal:
log.Println("KILL signaled!") // 호출되지 않음
os.Exit(0)
// ...[생략]...
}
이에 대해서는 공식 문서에도 나와 있습니다.
signal
; https://pkg.go.dev/os/signal
The signals SIGKILL and SIGSTOP may not be caught by a program, and therefore cannot be affected by this package.
마지막으로, Go 언어는 signal에 대한 기본 핸들러를 설치하지 않는데요, 그래서 등록되지 않은 signal을 받은 경우 강제 종료가 되는 것은 C/C++ 프로그램과 같습니다. 가령 HUP 시그널을 등록하지 않았다면,
terminateSignal := make(chan os.Signal)
interruptSignal := make(chan os.Signal)
signal.Notify(terminateSignal, syscall.SIGTERM)
signal.Notify(interruptSignal, syscall.SIGINT)
for {
select {
case <-terminateSignal: // systemctl kill
log.Println("TERM signaled!")
goto ExitProc
case <-interruptSignal: // systemctl stop (KillSignal = SIGINT)
log.Println("INT signaled!")
goto ExitProc
}
}
이런 상태에서 해당 프로세스에 대해 HUP 시그널을 보내면 바로 종료됩니다.
$ sudo kill -s SIGHUP $(pgrep -f go-sample-daemon) // 대상 프로세스가 HUP 시그널을 처리하지 않았으므로 강제 종료
기타, 위의 실습을 하면서 pgrep 명령어에 대해 알게 된 것이 하나 있는데요,
pgrep은 검색어가 15자를 넘어서면 안 된다는 제약이 있습니다.
그래서 이번 예제처럼 이름이 길면 실행 중이어도 결과가 나오지 않습니다.
$ pgrep go-sample-daemon
$
그래서 이렇게 15자 이하로 줄이거나,
$ pgrep go-sample-daemo
1748955
-f 옵션을 사용해 16자 이상을 지원하도록 명시해야 합니다.
$ pgrep -f go-sample-daemon
1748955
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]