Windows/linux의 service 를 다루는 차이

Windows에서 서비스라고 부르는 / linux 혹은 *nix 계열의 OS들에선 daemon 이라고 부르는 사용자와 직접 대화(?)하지 않고 컴퓨터가 켜지면 시작되서^[1] 끝날 때 까지 조용히(?) 돌고 있는 프로세스들이 있다. 이걸 관리하는 관점이 양쪽이 좀 다른데, (+그리고 헷갈려)

• Windows 에서는 services.msc 라는 관리자 페이지를 통해서 서비스를 켜고, 멈추고, 재시작한다.^[2] 반면에 *nix에서는 /etc/init.d/서비스이름 start/stop/restart 를 사용한다. 서비스 자체를 관리하는 명시적인 주체가 *nix에서는 존재하지 않는다^[3] 물론 양쪽 모두 KILL 신호를 보내서 죽이는게 가능하다…
• 설정 파일을 다시 읽는 법이 표준화되지 않은 Windows — 거의 개별 프로세스 재량에 맡김. SIGHUP 을 통해 설정 파일을 다시 읽는 *nix. 사실 이건 프로그래밍 모델에 가까운 얘기인데 — 즉 우열의 문제랑은 좀 거리가 있다 — *nix 세계에서 서비스 설정파일을 다시 읽는 것은 아주 잘 지켜지는 관례로 SIGHUP 시그널을 받으면 설정을 다시 읽는다! 라는 것으로 되어있다. Windows 에선 이런 관례가 없는지 보통은 그냥 서비스 재시작으로 때운다^[4]
• Windows 에서 서비스를 추가할 때에는 instsrv.exe^[5] 를 쓰거나해서 registry도 수정해줘야 한다 — 자세한 설정은 거의 registry에서 해야. 반면에 *nix 는 데몬 추가/설정 자체가 shell에서 실행시킨다는 느낌이라 rc.d 에 추가하는 것 외에는 별게 없음

뭔가 양쪽다 중앙 집권화를 적당히 하다만 느낌이고 안된 부분이 서로 달라서 양쪽 왔다갔다 하면서 쓸 때 헷갈리는 느낌 — 내 경우엔 윈도우에서 주로 삽질하지만;

ps. init의 경우 SIGHUP을 받으면 설정을 다시 읽는 것 마찬가진데, SIGKILL을 받으면 전체 서버가 재시작(…)하게 된다. 심심한 서버 관리자는 재부팅해야할 일이 있을 때 재미로 해볼 수도 있긴한데 추천은 안한다. 비슷하게 Windows도 커널 서비스를 실행해주는 svchost.exe 를 죽이다보면 OS가 재시작된다는 메시지를 볼 수 있다(…이런건 묘하게 비슷하다)

Windows 서비스 등록이 안된다는 보고에 대한 디버깅

전에 작성한 서버 프로그램이 서비스로 제대로 등록안된다고 해서^[6] 디버깅을 하는데, 프로세스가 읽어들이는 설정 파일에 상대 경로가 몇 개 있더군. 이걸 수정하니 종료. 아무래도 이건 shell script로 실행하는 것 에 익숙해져서 그런건가 -_-;; — 물론 그 쪽 세계에서도 경로 속이기(우선순위로) 문제 때문에 절대 경로를 쓸 것을 권장하긴 한다. 하지만 CWD의 상대 경로가 잘 안되는건 Orz

ps. 이유는 모르겠지만 (심지어 설명 페이지에도 제대로 설명이 없음), instsrv.exe/srvany.exe 에 대한 경로가 절대 경로가 아니면 실행도 되고, 화면 출력도 제대로 된 것 같이 나오고하는데, 서비스는 등록되지 않는 괴악한 일이 생긴다. 이걸로 작년 2월인가 3월에 삽질해본 기억이 있는데…

1. 혹은 특정 상황에서 작동을 시작하는 [↩]
2. 물론 Windows Powershell 등에는 커맨드라인에서 이런 동작을 가능하게 해주는 기능도 있다 [↩]
3. 하지만 묵시적인 주체로는 시작 프로세스인 init (pid=1)이 있고, serivces.msc 비슷한 관리 페이지를 GUI로 제공하는 linux distro. 들도 많다 [↩]
4. 물론 일부 프로그램은 설정 다시 읽기 기능을 제공하거나, 양쪽다 일부 프로그램에서 채용하는 watch-dog thread 방식으로 설정 파일이 변경되는지 감시하기도 한다. [↩]
5. Windows Resource Toolkit 에 있는 녀석. 이거랑 srvany.exe 를 쓰면 Unix daemon 코드 만드는 느낌으로 뚝딱(…) 만들어낼 수 있다 [↩]
6. 위에서 언급한 srvany.exe / instsrv.exe를 써서 [↩]