Windows/linux의 service 를 다루는 차이

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

• Windows 에서는 services.msc 라는 관리자 페이지를 통해서 서비스를 켜고, 멈추고, 재시작한다. ((물론 Windows Powershell 등에는 커맨드라인에서 이런 동작을 가능하게 해주는 기능도 있다)) 반면에 *nix에서는 /etc/init.d/서비스이름 start/stop/restart 를 사용한다. 서비스 자체를 관리하는 명시적인 주체가 *nix에서는 존재하지 않는다 ((하지만 묵시적인 주체로는 시작 프로세스인 init (pid=1)이 있고, serivces.msc 비슷한 관리 페이지를 GUI로 제공하는 linux distro. 들도 많다)) 물론 양쪽 모두 KILL 신호를 보내서 죽이는게 가능하다…
• 설정 파일을 다시 읽는 법이 표준화되지 않은 Windows — 거의 개별 프로세스 재량에 맡김. SIGHUP 을 통해 설정 파일을 다시 읽는 *nix. 사실 이건 프로그래밍 모델에 가까운 얘기인데 — 즉 우열의 문제랑은 좀 거리가 있다 — *nix 세계에서 서비스 설정파일을 다시 읽는 것은 아주 잘 지켜지는 관례로 SIGHUP 시그널을 받으면 설정을 다시 읽는다! 라는 것으로 되어있다. Windows 에선 이런 관례가 없는지 보통은 그냥 서비스 재시작으로 때운다 ((물론 일부 프로그램은 설정 다시 읽기 기능을 제공하거나, 양쪽다 일부 프로그램에서 채용하는 watch-dog thread 방식으로 설정 파일이 변경되는지 감시하기도 한다.))
• Windows 에서 서비스를 추가할 때에는 instsrv.exe ((Windows Resource Toolkit 에 있는 녀석. 이거랑 srvany.exe 를 쓰면 Unix daemon 코드 만드는 느낌으로 뚝딱(…) 만들어낼 수 있다)) 를 쓰거나해서 registry도 수정해줘야 한다 — 자세한 설정은 거의 registry에서 해야. 반면에 *nix 는 데몬 추가/설정 자체가 shell에서 실행시킨다는 느낌이라 rc.d 에 추가하는 것 외에는 별게 없음

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

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

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

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

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