Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 3개 있습니다.)
Linux: 18. C# - .NET Core Console로 리눅스 daemon 프로그램 만드는 방법
; https://www.sysnet.pe.kr/2/0/11958

C/C++: 186. Golang - 콘솔 응용 프로그램을 NT 서비스를 지원하도록 변경
; https://www.sysnet.pe.kr/2/0/13854

C/C++: 187. Golang - 콘솔 응용 프로그램을 Linux 데몬 서비스를 지원하도록 변경
; https://www.sysnet.pe.kr/2/0/13857




Golang - 콘솔 응용 프로그램을 NT 서비스를 지원하도록 변경

이번 글은 아래의 내용을 베낀 정리한 것입니다.

Writing a windows service in Go
; https://dev.to/cosmic_predator/writing-a-windows-service-in-go-1d1m




go 언어로 단순한 유형의 콘솔 애플리케이션을 만들어 직접 실습해 볼 텐데요, 이를 위해 아래와 같은 초기화 작업을 먼저 진행하고,

c:\temp\go_sample> go mod init sample_svc
go: creating new go.mod: module sample_svc

C:\temp\go_sample> type go.mod
module go_sample

go 1.22

toolchain go1.22.10

require golang.org/x/sys v0.27.0

대충 main은 이런 식으로 만들겠습니다.

package main

import (
    "bufio"
    "log"
    "os"
)

func doMyWork() {
	tick := time.Tick(1 * time.Second)

	for {
		select {
		case <-tick:
			log.Println("Tick Handled (Console)...!")
		}
	}
}

func main() {
    go doMyWork(false)

    log.Println("Press any key to exit...")
    input := bufio.NewScanner(os.Stdin)
    input.Scan()
}

보는 바와 같이 doMyWork 함수가 1초마다 log를 출력하는 작업만 수행하는데 일단은 저걸 NT 서비스의 주요 작업이라고 보면 되겠습니다.

자, 그럼 이제 이 프로그램을 NT 서비스로 만들어 볼 텐데요, go 언어에서는 이를 위해 svc 패키지를 제공하므로 이에 준하는 규칙에 따라 작성하시면 됩니다.

우선, svc 패키지에는 Execute 함수 하나를 정의한 Handler 인터페이스가 구현돼 있는데요,

type Handler interface {
    Execute(args []string, r <-chan ChangeRequest, s chan<- Status) (svcSpecificEC bool, exitCode uint32)
}

따라서 우리는 저 인터페이스를 구현한 개체를 만들면 됩니다.

type myService struct{}

func (m *myService) Execute(args []string, r <-chan svc.ChangeRequest, status chan<- svc.Status) (bool, uint32) {
    const cmdsAccepted = svc.AcceptStop | svc.AcceptShutdown | svc.AcceptPauseAndContinue

    // if need long-init
    // status <- svc.Status{State: svc.StartPending}
    // ...init work...

    log.Print("Starting service...!")
    go doMyWork(false)

    status <- svc.Status{State: svc.Running, Accepts: cmdsAccepted}

loop:
    for {
        select {
        case c := <-r:
            switch c.Cmd {
            case svc.Interrogate:
                status <- c.CurrentStatus
            case svc.Stop, svc.Shutdown:
                log.Print("Shutting service...!")
                break loop
            case svc.Pause:
                status <- svc.Status{State: svc.Paused, Accepts: cmdsAccepted}
            case svc.Continue:
                status <- svc.Status{State: svc.Running, Accepts: cmdsAccepted}
            default:
                log.Printf("Unexpected service control request #%d", c)
            }
        }
    }

    // if need long-clean-up (참고: https://www.sysnet.pe.kr/2/0/13861#go_stop_pending)
    // status <- svc.Status{State: svc.StopPending}
    // ...cleanup...

    status <- svc.Status{State: svc.Stopped}
    return false, 1
}

Execute 함수의 내부 로직을 보면 대충 이렇게 나뉩니다.

  1. Execute가 수행된 것 자체가 이미 서비스를 "Start" 시킨 것으로 간주하고, "서비스 작업"을 (다른 스레드로) 수행한다.
  2. 이후, 무한 루프를 돌면서 SCM(Service Control Manager)으로부터 받은 명령에 따라 적절한 동작을 수행한다.
  3. "Stop" 명령을 받으면 무한 루프를 벗어나고, 서비스가 정상적으로 "Stopped" 상태로 빠졌음을 SCM에게 알린다.

위의 "1번" 작업에 해당하는 코드를 보면,

const cmdsAccepted = svc.AcceptStop | svc.AcceptShutdown | svc.AcceptPauseAndContinue

// if need long-init
// status <- svc.Status{State: svc.StartPending}
// ...init work...

log.Print("Starting service...!")
go doMyWork() // 사용자가 서비스를 "Start" 시킨 것이므로 서비스로써의 작업을 수행한다.

status <- svc.Status{State: svc.Running, Accepts: cmdsAccepted} // 서비스가 Running 상태임을 SCM에 알린다.

가장 중요한 것은 svc.Status를 이용해 서비스가 "Running" 상태로 전환했음을 알리는 것입니다. 만약, 이 코드를 누락하면 SCM은 해당 서비스가 시작됐는지 알 수 없게 돼 "진행 중"을 표시하는 progress bar가 무한히 돌아가게 됩니다.

그리고 사용자 작업을 "동기" 방식으로 실행해서는 안 된다는 점이 중요합니다. 보통 다른 언어(C/C++)로 작성한 경우라면 저 부분을 CreateThread를 이용해 별도의 스레드로 작업을 맡기지만 go 언어의 경우 고루틴을 이용하면 됩니다.

여기까지 진행이 되었으면 이제 SCM은 서비스가 시작 중임을 인지하게 됐고, 서비스 입장에서도 자신의 고유 작업을 수행하게 됐습니다.

참고로, 위의 코드에서 주석 처리한 StartPending은 서비스를 시작할 때 초기화 작업이 길어지는 경우 SCM 측에 중간 상태를 알려주기 위해 필요합니다. 이번 예제에서는 작업자 코드가 곧바로 수행될 것이므로 굳이 필요하지는 않은 경우입니다.




자, 그럼 2번 단계로 가볼까요?

loop:
    for {
        select {
        case c := <-r:
            switch c.Cmd {
            case svc.Interrogate:
                status <- c.CurrentStatus
            case svc.Stop, svc.Shutdown:
                log.Print("Shutting service...!")
                break loop
            case svc.Pause:
                status <- svc.Status{State: svc.Paused, Accepts: cmdsAccepted}
            case svc.Continue:
                status <- svc.Status{State: svc.Running, Accepts: cmdsAccepted}
            default:
                log.Printf("Unexpected service control request #%d", c)
            }
        }
    }

우선, Pause/Continue는 의미하는 바에 따라 해당 신호를 받은 경우에는 doMyWork 내부에서 작업을 skip/continue하도록 반응해 주면 됩니다.

그리고 가장 중요한 Stop/Shutdown의 경우 응용 프로그램을 종료하면 되므로 저 루프를 벗어나게 하면 됩니다. 그럼 3번 단계로 바뀌는데요,

// if need long-clean-up
// status <- svc.Status{State: svc.StopPending}
// ...cleanup...

status <- svc.Status{State: svc.Stopped}

이것 역시 이전에 설명했던 StartPending / Running 관계처럼 다루면 됩니다. 즉, 서비스를 종료하는 작업이 오래 걸릴 것 같으면 StopPending으로 우선 SCM에게 알려주고, 이후 완전히 서비스가 종료했을 때 Stopped를 통보하면 됩니다.

딱히 어렵지 않죠? ^^




위와 같이 SCM에 의해 callback을 처리하는 Handler를 만들었으면 이제 main 함수에 이를 반영하면 됩니다. 단지 Console에서 직접 실행하는 경우는 go doMyWork()를 호출한 이후 응용 프로그램 종료를 막기 위해 Scanner.Scan 함수를 일부러 호출했었는데요, svc 패키지의 경우 이런 블록을 svc.Run 함수에서 해주기 때문에 다음과 같이 간단하게 처리할 수 있습니다.

func main() {
    
    err := svc.Run("go_sample_svc", &myService{}) // 블록킹 함수
    if err != nil { // 서비스 "stop"을 한 경우에만 제어가 반환돼 이 코드를 실행
        log.Println("Error running service in Service Control mode.")
    }
}

끝입니다. ^^ 이제 저 프로그램을 빌드해 go_svc_sample.exe를 만들고 이를 NT 서비스로 등록하는 것으로 마무리를 합니다.

c:\temp> go build -ldflags "-s -w" -o go_svc_sample.exe

// 관리자 권한 필요
c:\temp> sc create go_sample_svc binPath= "C:\temp\go_sample\go_svc_sample.exe" start= auto 

이후, "서비스 관리자"를 열어 "go_sample_svc" 서비스를 시작/중지하는 식으로 테스트할 수 있습니다.




그런데, 서비스 프로그램을 만들어 보신 분은 알겠지만 이렇게 프로그램을 만드는 경우 SCM으로만 실행할 수 있으므로 개발 및 디버깅이 여간 불편한 것이 아닙니다.

따라서, 개발 편의를 위해 콘솔 모드로 실행하는 옵션을 추가하는 것이 좋은데요, 가령, 위의 예제는 다음과 같은 식으로 변경할 수 있습니다.

package main

import (
    "bufio"
    "fmt"
    "github.com/alecthomas/kingpin"
    "golang.org/x/sys/windows/svc"
    "log"
    "os"
    "time"
)


var (
    console_mode = kingpin.Flag("c", "Run in console").Default("false").Bool()
)

func main() {
    kingpin.Parse()

    if *console_mode == true {
        go doMyWork()

        log.Println("Press any key to exit...")
        input := bufio.NewScanner(os.Stdin)
        input.Scan()
    } else {
        err := svc.Run("go_sample_svc", &myService{})
        if err != nil {
            log.Println("Error running service in Service Control mode.")
        }
    }
}

이렇게 해주면 개발 시에는 명령행 인자를 줘서 편리하게 F5 디버깅을 할 수 있습니다.

c:\temp> go_svc_sample.exe --console

물론, 저렇게 콘솔로 실행하는 경우의 Interactive 세션 환경과 SCM에 의해 실행되는 Service 세션 환경의 보안이 다르므로 그런 부분은 주의해서 테스트를 해야 합니다.

아울러, NT 서비스로 실행하는 동안 문제가 발생하는 경우를 진단하기 위해 로그 파일을 남기는 것도 좋은 방법이므로,

func main() {
    kingpin.Parse()

    if *console_mode == true {
        // ...[생략]...
    } else {
        f, err := os.OpenFile("C:/temp/debug.log", os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
        if err != nil {
            log.Fatalln(fmt.Errorf("error opening file: %v", err))
        }
        defer func(f *os.File) {
            _ = f.Close()
        }(f)

        log.SetOutput(f)

        err = svc.Run("go_sample_svc", &myService{})
        if err != nil {
            log.Println("Error running service in Service Control mode.")
        }
    }
}

위와 같이 log.SetOutput 함수를 사용하는 것이 필수입니다. 좋습니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




원문의 소스코드에 버그가 살짝 있는데요, Execute의 마지막 단계에서 StopPending 호출만 하고 있습니다.

func (m *myService) Execute(args []string, r <-chan svc.ChangeRequest, status chan<- svc.Status) (bool, uint32) {

    // ...[생략]...
    status <- svc.Status{State: svc.StopPending}
    return false, 1
}

저렇게 종료하면 SCM은 정상적으로 서비스가 Stopped 상태로 전환됐다고 인지하지 못하므로 "서비스 관리자"에서 중지시켜 보면 이런 오류가 발생합니다.

Windows could not stop the go_sample_svc service on Local Computer.

Error 1: Incorrect function.

따라서 제가 본문에서 설명한 것처럼 "status <- svc.Status{State: svc.Stopped}" 코드로 끝맺음해야 합니다.




참고로, Go 언어의 결과물은 1.20 버전까지만 Windows 7/2008 R2를 지원합니다.

Cannot run go programs built with 1.21.5 on Windows Server anymore #64602
; https://github.com/golang/go/issues/64602

그 이상의 버전으로 빌드한 결과물을 Windows 8/2012 미만의 환경에서 실행하면 이런 결과가 나옵니다.

C:\temp> testapp.exe
Exception 0xc0000005 0x8 0x0 0x0
PC=0x0

runtime.asmstdcall(0x2d0700060009)
        runtime/sys_windows_amd64.s:76 +0x89 fp=0xf5f680 sp=0xf5f660 pc=0x397609
rax     0x0
rbx     0x920100
rcx     0x965f28
rdx     0x20
rdi     0x7fffffde000
rsi     0xf5f878
rbp     0xf5f7c0
rsp     0xf5f658
r8      0x91fe20
r9      0x965a4a
r10     0xc7a2e8
r11     0xc000004000
r12     0xf5f8c8
r13     0x0
r14     0x91ef80
r15     0x3
rip     0x0
rflags  0x10246
cs      0x33
fs      0x53
gs      0x2b

별 의미는 없지만 오류가 발생한 소스코드를 보면,

go/src/runtime/sys_windows_amd64.s
; https://github.com/golang/go/blob/master/src/runtime/sys_windows_amd64.s#L74

아래의 "CALL AX"에서 오류가 발생한 것이고,

...[생략]...

// void runtime·asmstdcall(void *c);
TEXT runtime·asmstdcall(SB),NOSPLIT,$16
    MOVQ    SP, AX
    ANDQ    $~15, SP    // alignment as per Windows requirement
    MOVQ    AX, 8(SP)
    MOVQ    CX, 0(SP)   // asmcgocall will put first argument into CX.

    MOVQ    libcall_fn(CX), AX
    MOVQ    libcall_args(CX), SI
    MOVQ    libcall_n(CX), CX

    // SetLastError(0).
    
    ...[생략]...
_1args:
    MOVQ    0(SI), CX
    MOVQ    CX, X0
_0args:

    // Call stdcall function.
    CALL    AX

    ADDQ    $(const_maxArgs*8), SP

    ...[생략]...

    RET
...[생략]...

AX에 기록된 값이 libcall_fn(CX)에서 읽어온 값인데, 이 값이 0이라서 오류가 발생한 것입니다. 그래서 call로 인해 점프한 곳도 0이고, 그때의 rax 값도 0입니다.

Exception 0xc0000005 0x8 0x0 0x0
PC=0x0 // Program Counter: RIP

runtime.asmstdcall(0x2d0700060009)
        runtime/sys_windows_amd64.s:76 +0x89 fp=0xf5f680 sp=0xf5f660 pc=0x397609
rax     0x0
rbx     0x920100
...[생략]...




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 1/11/2025]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13883정성태2/12/2025189닷넷: 2317. C# - Memory Mapped I/O를 이용한 PCI Configuration Space 정보 열람파일 다운로드1
13882정성태2/10/2025584스크립트: 70. 파이썬 - oracledb 패키지 연동 시 Thin / Thick 모드
13881정성태2/7/2025897닷넷: 2316. C# - Port I/O를 이용한 PCI Configuration Space 정보 열람파일 다운로드1
13880정성태2/5/2025870오류 유형: 947. sshd - Failed to start OpenSSH server daemon.
13879정성태2/5/20251107오류 유형: 946. Ubuntu - N: Updating from such a repository can't be done securely, and is therefore disabled by default.
13878정성태2/3/2025987오류 유형: 945. Windows - 최대 절전 모드 시 DRIVER_POWER_STATE_FAILURE 발생 (pacer.sys)
13877정성태1/25/20251082닷넷: 2315. C# - PCI 장치 열거 (레지스트리, SetupAPI)파일 다운로드1
13876정성태1/25/20251274닷넷: 2314. C# - ProcessStartInfo 타입의 Arguments와 ArgumentList파일 다운로드1
13875정성태1/24/20251264스크립트: 69. 파이썬 - multiprocessing 패키지의 spawn 모드로 동작하는 uvicorn의 workers
13874정성태1/24/20251212스크립트: 68. 파이썬 - multiprocessing Pool의 기본 프로세스 시작 모드(spawn, fork)
13873정성태1/23/20251107디버깅 기술: 217. WinDbg - PCI 장치 열거
13872정성태1/23/20251089오류 유형: 944. WinDbg - 원격 커널 디버깅이 연결은 되지만 Break (Ctrl + Break) 키를 눌러도 멈추지 않는 현상
13871정성태1/22/20251201Windows: 278. Windows - 윈도우를 다른 모니터 화면으로 이동시키는 단축키 (Window + Shift + 화살표)
13870정성태1/18/20251275개발 환경 구성: 741. WinDbg - 네트워크 커널 디버깅이 가능한 NIC 카드 지원 확대
13869정성태1/18/20251329개발 환경 구성: 740. WinDbg - _NT_SYMBOL_PATH 환경 변수에 설정한 경로로 심벌 파일을 다운로드하지 않는 경우
13868정성태1/17/20251233Windows: 277. Hyper-V - Windows 11 VM의 Enhanced Session 모드로 로그인을 할 수 없는 문제
13867정성태1/17/20251396오류 유형: 943. Hyper-V에 Windows 11 설치 시 "This PC doesn't currently meet Windows 11 system requirements" 오류
13866정성태1/16/20251359개발 환경 구성: 739. Windows 10부터 바뀐 device driver 서명 방법
13865정성태1/15/20251477오류 유형: 942. C# - .NET Framework 4.5.2 이하의 버전에서 HttpWebRequest로 https 호출 시 "System.Net.WebException" 예외 발생
13864정성태1/15/20251427Linux: 114. eBPF를 위해 필요한 SELinux 보안 정책
13863정성태1/14/20251320Linux: 113. Linux - 프로세스를 위한 전용 SELinux 보안 문맥 지정
13862정성태1/13/20251283Linux: 112. Linux - 데몬을 위한 SELinux 보안 정책 설정
13861정성태1/11/20251792Windows: 276. 명령행에서 원격 서비스를 동기/비동기로 시작/중지
13860정성태1/10/20251740디버깅 기술: 216. WinDbg - 2가지 유형의 식 평가 방법(MASM, C++)
13859정성태1/9/20251850디버깅 기술: 215. Windbg - syscall 이후 실행되는 KiSystemCall64 함수 및 SSDT 디버깅
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...