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를 써서 []

Published by

rein

나는 ...

4 thoughts on “Windows/linux의 service 를 다루는 차이”

  1. 윈도우 서비스 개발이 참 어렵지요. 콘솔이나 윈도우 창 같은 인터페이스가 없으니 서비스 중에 문제가 생겨도 원인 찾기가 쉽지 않고, 천상 껏다 켜는 게 상책이라…..

    윈도우 서비스 개발할 때 제일 처음 하는 일이 로그 쪽을 완비하고, 콘솔 모드(개발시)와 서비스 모드(운영시)를 자연스럽게 전환해주는 코드를 짜는 거지요. 솔직히 특별한 일 아니면 서비스로는 짜고 싶지 않아요. 크.

  2. 윈도우 서비스도 그렇지만 linux daemon들도 로그에 의존해서 디버깅해야하기는 마찬가지죠. 사람이 직접 볼 수 없다는게(?) 좀 괴롭게 해주는듯…

    특별한 일 아니면 서비스로 짜고싶지 않긴한데, 이번에 서비스로 등록해달라고해서 instsrv + srvany 꼼수로 전환을 (로그는 log4cxx등을 써서 이미 다 설정가능하게 분리해서) 했지요;

  3. 근데…윈도쪽에서는 서비스가 아니면 어떤상황에서든 돌아가고있는 프로그램을 짜기가…^^; 시작프로그램에 넣어놓는다고 해봐야 사용자 로그인을 하지않으면, 실행이 되지않으니까요. (물론…특정 사용자로 지정해서 실행하는 꼼수가 있긴하지만요)

    이래저래…코어덤프 기능을 활용하지않으면…좀 불편하죠 ㅎㅎ

  4. 어떤 상황에서든 돌아가는 프로그램은 daemon 스러운 혹은 서비스스러운 방법 말고는 없겠죠;;

    코어덤프야 스냅샷이고 로그도 덤프만큼 중요하지 않을까요 ~_~

Leave a Reply