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월에 삽질해본 기억이 있는데…
- 혹은 특정 상황에서 작동을 시작하는 [↩]
- 물론 Windows Powershell 등에는 커맨드라인에서 이런 동작을 가능하게 해주는 기능도 있다 [↩]
- 하지만 묵시적인 주체로는 시작 프로세스인 init (pid=1)이 있고, serivces.msc 비슷한 관리 페이지를 GUI로 제공하는 linux distro. 들도 많다 [↩]
- 물론 일부 프로그램은 설정 다시 읽기 기능을 제공하거나, 양쪽다 일부 프로그램에서 채용하는 watch-dog thread 방식으로 설정 파일이 변경되는지 감시하기도 한다. [↩]
- Windows Resource Toolkit 에 있는 녀석. 이거랑 srvany.exe 를 쓰면 Unix daemon 코드 만드는 느낌으로 뚝딱(…) 만들어낼 수 있다 [↩]
- 위에서 언급한 srvany.exe / instsrv.exe를 써서 [↩]
윈도우 서비스 개발이 참 어렵지요. 콘솔이나 윈도우 창 같은 인터페이스가 없으니 서비스 중에 문제가 생겨도 원인 찾기가 쉽지 않고, 천상 껏다 켜는 게 상책이라…..
윈도우 서비스 개발할 때 제일 처음 하는 일이 로그 쪽을 완비하고, 콘솔 모드(개발시)와 서비스 모드(운영시)를 자연스럽게 전환해주는 코드를 짜는 거지요. 솔직히 특별한 일 아니면 서비스로는 짜고 싶지 않아요. 크.
윈도우 서비스도 그렇지만 linux daemon들도 로그에 의존해서 디버깅해야하기는 마찬가지죠. 사람이 직접 볼 수 없다는게(?) 좀 괴롭게 해주는듯…
특별한 일 아니면 서비스로 짜고싶지 않긴한데, 이번에 서비스로 등록해달라고해서 instsrv + srvany 꼼수로 전환을 (로그는 log4cxx등을 써서 이미 다 설정가능하게 분리해서) 했지요;
근데…윈도쪽에서는 서비스가 아니면 어떤상황에서든 돌아가고있는 프로그램을 짜기가…^^; 시작프로그램에 넣어놓는다고 해봐야 사용자 로그인을 하지않으면, 실행이 되지않으니까요. (물론…특정 사용자로 지정해서 실행하는 꼼수가 있긴하지만요)
이래저래…코어덤프 기능을 활용하지않으면…좀 불편하죠 ㅎㅎ
어떤 상황에서든 돌아가는 프로그램은 daemon 스러운 혹은 서비스스러운 방법 말고는 없겠죠;;
코어덤프야 스냅샷이고 로그도 덤프만큼 중요하지 않을까요 ~_~