daemon 프로세스는 프로그램 시작할때에 공유메모리에 접근하여 공유메모리리에 pid가 없으면 자신의 pid를 적고, 공유메모리가 존재하고, 거기에 적혀있는 pid값이 존재할때 pid에 해당하는 프로세스가 존재하는지 체크한 후 존재하면 죽는 방식으로 진행됩니다.
결국 startup 하는 프로그램과 shutdown 하는 프로그램을 별도로 구현하는것이 좋으며, 이때 startup 프로그램은 공유메모리 로드, daemon 프로세스 fork/exec 등의 행위를... shutdown 프로그램은 daemon에게 signal 을 보내고, 종료확인 후 공유메모리 제거... 등의 행위를 합니다.
이미원래데몬은 실행이비정상종료된상태이고
이때 비슷하거나 같은이름의 프로그램이 실행되었는데 운이 좋게도 비정상종료
되었던 프로세스ID 와 같은 Pid 를 가지고 실행되고 있다면 어떻게 될까요..
그러면 결과는 다른프로세스가 실행되고 있는데 자신이 실행된다고 오판을
하겠죠..
물론이런경우가 우연히 일어날경우는 평생가봐야 거의 없겠죠...
하지만 어떤일반유저중에 악의적으로 접근한다면 충분히 상황을 만들어낼수
있지 않을까요..
daemon 프로세스는 프로그램 시작할때에 공유메모리에 접근하여 공유메모리리에 pid가 없으면 자신의 pid를 적고, 공유메모리가 존재하고, 거기에 적혀있는 pid값이 존재할때 pid에 해당하는 프로세스가 존재하는지 체크한 후 존재하면 죽는 방식으로 진행됩니다.
결국 startup 하는 프로그램과 shutdown 하는 프로그램을 별도로 구현하는것이 좋으며, 이때 startup 프로그램은 공유메모리 로드, daemon 프로세스 fork/exec 등의 행위를... shutdown 프로그램은 daemon에게 signal 을 보내고, 종료확인 후 공유메모리 제거... 등의 행위를 합니다.
그런 경우를 생각할 수 있을 겁니다만...
실행파일의 path를 포함해서 같은 프로그램이 실행되고 있는지 확인한다면 별 문제가 없겠죠.
path까지 똑같은 프로그램이라면 어차피 같은 프로그램일테니까요.
ㅡ,.ㅡ;; wrote:
아래와 같이 할경우
이미원래데몬은 실행이비정상종료된상태이고
이때 비슷하거나 같은이름의 프로그램이 실행되었는데 운이 좋게도 비정상종료
되었던 프로세스ID 와 같은 Pid 를 가지고 실행되고 있다면 어떻게 될까요..
그러면 결과는 다른프로세스가 실행되고 있는데 자신이 실행된다고 오판을
하겠죠..
물론이런경우가 우연히 일어날경우는 평생가봐야 거의 없겠죠...
하지만 어떤일반유저중에 악의적으로 접근한다면 충분히 상황을 만들어낼수
있지 않을까요..
lock 파일과 그 내용으로 중복실행을 방지하는 방법은 꽤 괜찮습니다.
shell script 에서 다루기에도 편하고 C api 까지 있으니 금상첨화죠.
비정상 종료 후 그 pid 로 다른 프로세스가 실행될 가능성이 지극히 낮기는 하지만 zero 가 아니므로 문제가 될 여지는 있습니다.
하지만,
/var/run/ 등은 부팅 때 깨끗하게 지워지는 곳이므로 리부팅 때 데몬이... 하는 걱정은 접어도 되고,
제대로 된 데몬이라면 signal 핸들러나 exit 핸들러 등에서 꼼꼼하게 처리하니 더더욱.
일반적인 응용 프로그램이라면 '이러러저해서 실행을 그만두겠습니다. 다시한번 확인해보시지요.' 정도의 정중한 안내 메시지를 보여주는 방법을 사용하면 그만입니다.
좀 더 진보적인 방법도 있습니다. (kldp 에도 언젠가 쓴 것 같은데...)
/tmp/ 나 홈디렉토리에 적절한 이름의 unix domain socket 을 만듭니다.
이미 존재하고, 특정한 패킷을 날렸을 때 특정한 응답이 오면 먼저 실행된 놈이 있다는 뜻입니다.
한발 더 나가서, 먼저 실행된 놈이 서버 역할을 하고 나중에 실행된 놈은 클라이언트 역할을 할 수도 있습니다.
xmms 가 이 방법을 사용합니다.(2003이면 xmms 의 전성기 무렵인데...)
나중에 실행된 놈은 먼저 실행된 놈을 원격제어(play,stop,pause 등등)할 수 있습니다.
xmms dock applet 이 많은 이유가 바로 이것 때문입니다.
(버전은 기억이 잘 안나는데... xmms 의 후기버전은 이 부분만 따로 떼서 libxmms 인가하는 이름의 라이브러리를 만들어 사용했습니다. 애초부터 코드 분리가 잘 되어 있었으니...뭐...)
요즘은 gnome 의 dbus, KDE 의 머시기등 message bus/router 들이 잘 규격화 되어 있으니
gnome application, KDE application 을 제작하는 경우엔 이런 framework 을 활용하는 편이 좋겠습니다.
bonobo(orbit?)을 사용하면 데이타의 공유까지도 가능하니 응용의 폭도 더 넓어지겠고요.
잘은 모르겠는데... 보통 데몬들 보면처음실행될때 자신의 PID 를
잘은 모르겠는데... 보통 데몬들 보면
처음실행될때 자신의 PID 를 저장해 놓고
이 PID 를 확인하는 방법을 써서 중복실행을 막는것 같더군요..
/var/run/ 보면 여러 데몬들의 PID 가 저장되있 구요...
from saibi
PID를 사용하는 방법은 좋기는 한데...
만약에 프로그램이 비정상 적으로 종료를 하게 되서...
PID가 그냥 남아 있는 상태에서 프로그램을 실행하면
이미 프로그램이 떠 있는것으로 판단하게 됩니다.
그래서 그 방법은 포기했습니다.
더 좋은 방법은 없을까요?
제 경우에는 공유메모리와 모니터링 프로세스를 사용했습니다.공유메모
제 경우에는 공유메모리와 모니터링 프로세스를 사용했습니다.
공유메모리에 daemon 의 pid와 그밖의 정보들을 적어두고... 일정 시간마다 모니터링 프로세스가 공유메모리를 검사하고 공유메모리에 접근하여 적혀있는 pid로 프로세스가 존재하는지 체크하는 방식입니다.
daemon 프로세스는 프로그램 시작할때에 공유메모리에 접근하여 공유메모리리에 pid가 없으면 자신의 pid를 적고, 공유메모리가 존재하고, 거기에 적혀있는 pid값이 존재할때 pid에 해당하는 프로세스가 존재하는지 체크한 후 존재하면 죽는 방식으로 진행됩니다.
결국 startup 하는 프로그램과 shutdown 하는 프로그램을 별도로 구현하는것이 좋으며, 이때 startup 프로그램은 공유메모리 로드, daemon 프로세스 fork/exec 등의 행위를... shutdown 프로그램은 daemon에게 signal 을 보내고, 종료확인 후 공유메모리 제거... 등의 행위를 합니다.
우리 모두 리얼리스트가 되자. 그러나 가슴에 이룰 수 없는 꿈을 가지자
별로 상관 없지 않나 싶습니다.pid 파일을 만들어 놓았기 때문에,
별로 상관 없지 않나 싶습니다.
pid 파일을 만들어 놓았기 때문에, pid로 프로세스의 정보를 찾아봐서
프로세스가 없으면 좋구, 프로세스가 있으면, 실행한 명령이 자신이 맞는지 확인하면 되구...
이렇게 구현하시면 될 것 같습니다.
그럼...
서명:
이것은 올리는 글에 첨부될 사인 문구입니다. 제한은 255 글자입니다
마지막분 감사합니다.
그런 좋은 아이디어가 있었네요.
저장된 PID로 부터 현재 정보를 가져오게 한 다음에
정보를 가져오면 떠 있는것으로 간주해서 마지막 실행을
종료하고, 그렇지 않은 경우에는 프로그램을 실행해서
현재 PID를 저장하고... 흐흐~
감사합니다.
저는 demon을 띠울때, 일단 pid를 pid파일에 적어 놓구 demo
저는 demon을 띠울때, 일단 pid를 pid파일에 적어 놓구 demon을 띠우는 script로
데몬의 pid를 grep해서 pid파일과 확인해서 일치하면 떠있는 것으로 간주하니ㄲ
중복실행되는 일이 한번도 없었었습니다...
방가워~~ ^^*
아주 작은 헛점이 있는것 같은데요..
아래와 같이 할경우
이미원래데몬은 실행이비정상종료된상태이고
이때 비슷하거나 같은이름의 프로그램이 실행되었는데 운이 좋게도 비정상종료
되었던 프로세스ID 와 같은 Pid 를 가지고 실행되고 있다면 어떻게 될까요..
그러면 결과는 다른프로세스가 실행되고 있는데 자신이 실행된다고 오판을
하겠죠..
물론이런경우가 우연히 일어날경우는 평생가봐야 거의 없겠죠...
하지만 어떤일반유저중에 악의적으로 접근한다면 충분히 상황을 만들어낼수
있지 않을까요..
================원문=========================
----------------------------------------------------------------------------
Re: 아주 작은 헛점이 있는것 같은데요..
그런 경우를 생각할 수 있을 겁니다만...
실행파일의 path를 포함해서 같은 프로그램이 실행되고 있는지 확인한다면 별 문제가 없겠죠.
path까지 똑같은 프로그램이라면 어차피 같은 프로그램일테니까요.
서명:
이것은 올리는 글에 첨부될 사인 문구입니다. 제한은 255 글자입니다
스크립 하는 방법을 몰라서...;;;
데몬프로그램 중복 방지.
2003년이면 리눅스
2003년이면 리눅스 사용자들이 꽤 되던 시절이었는데...
lock 파일과 그 내용으로 중복실행을 방지하는 방법은 꽤 괜찮습니다.
shell script 에서 다루기에도 편하고 C api 까지 있으니 금상첨화죠.
비정상 종료 후 그 pid 로 다른 프로세스가 실행될 가능성이 지극히 낮기는 하지만 zero 가 아니므로 문제가 될 여지는 있습니다.
하지만,
/var/run/ 등은 부팅 때 깨끗하게 지워지는 곳이므로 리부팅 때 데몬이... 하는 걱정은 접어도 되고,
제대로 된 데몬이라면 signal 핸들러나 exit 핸들러 등에서 꼼꼼하게 처리하니 더더욱.
일반적인 응용 프로그램이라면 '이러러저해서 실행을 그만두겠습니다. 다시한번 확인해보시지요.' 정도의 정중한 안내 메시지를 보여주는 방법을 사용하면 그만입니다.
좀 더 진보적인 방법도 있습니다. (kldp 에도 언젠가 쓴 것 같은데...)
/tmp/ 나 홈디렉토리에 적절한 이름의 unix domain socket 을 만듭니다.
이미 존재하고, 특정한 패킷을 날렸을 때 특정한 응답이 오면 먼저 실행된 놈이 있다는 뜻입니다.
한발 더 나가서, 먼저 실행된 놈이 서버 역할을 하고 나중에 실행된 놈은 클라이언트 역할을 할 수도 있습니다.
xmms 가 이 방법을 사용합니다.(2003이면 xmms 의 전성기 무렵인데...)
나중에 실행된 놈은 먼저 실행된 놈을 원격제어(play,stop,pause 등등)할 수 있습니다.
xmms dock applet 이 많은 이유가 바로 이것 때문입니다.
(버전은 기억이 잘 안나는데... xmms 의 후기버전은 이 부분만 따로 떼서 libxmms 인가하는 이름의 라이브러리를 만들어 사용했습니다. 애초부터 코드 분리가 잘 되어 있었으니...뭐...)
요즘은 gnome 의 dbus, KDE 의 머시기등 message bus/router 들이 잘 규격화 되어 있으니
gnome application, KDE application 을 제작하는 경우엔 이런 framework 을 활용하는 편이 좋겠습니다.
bonobo(orbit?)을 사용하면 데이타의 공유까지도 가능하니 응용의 폭도 더 넓어지겠고요.
OTL
댓글 달기