간헐적으로 사망하는 프로세스에 대한 GDB 활용방안 문의
OS : CentOs 6.4 64bit
고객사에서 상시 실행중이여야 하는 프로세스가 간헐적으로 끊기는 것을 확인하였습니다
현재 보안규정상 서버 PC를 직접 조작이 불가능하여 VPN을 통해 접근하고 있습니다.
core file size (blocks, -c) unlimited
이와 같이 설정을 하고 설정 당시 임의로 core dump를 작성하는 시그널을 보내어
종료후 core파일이 생성되는것을 확인하였습니다.
문제는 실제 운영중 프로세스 daed 발생시에는 core파일이 생성되지 않습니다.
dead가 발생후에 back trace를 통해 소스중 어디에서 문제가 발생하였는지 추적해야 하는데
VPN의 연결 상태가 좋지 못하여 문제가 발생할때까지 SSH 터미널 연결이 유지되지 않습니다.
이런 이유로 아래와 같은 방법을 사용하려 합니다.
# gdb targetA "PID값"
(gdb) set logging on
(gdb) handle SIGPIPE nostop
마지막 라인은 임의로 SIGPIPE로 작성하였는데 cron 스케줄을 통하여 재시작되는 방식이다 보니 gdb로 인하여 stop 상태가 되면
동작은 동작대로 안하고 재시작도 안되기에 위와 같이 handle 옵션을 추가하는 방법을 사용하기로 하였습니다.
그런데 위 방법은 어떠한 시그널로 인하여 dead가 발생하였는지만 알 수 있습니다.
소스 코드에 모든 signal을 handle 하여 back trace 내용을 demangle 하여 출력하도로 하는 코드를 심었는데
위치가 적절하지 않은건지 테스트로 SIGSEGV를 유발하는 상황에서는 관련 로그를 확인할수 있었으나
운영중 발생한 사항에 대해서는 이 사항이 조건에 부합하지 않는지 로그를 확인할수가 없었습니다.
back trace 내용이나 어떤 방법으로라도 소스코드중 어느부분에서 문제가 발생하였는지
알고 싶은데 뭔가 방법이 없을까요?
두 가지 제안 드립니다. 1. "cron을 통해
두 가지 제안 드립니다.
1. "cron을 통해 재시작되는 방식"이고 "테스트 시에는 관련 로그를 확인"이지만 실제 환경에서는 확인이 되지 않았다면 signal을 handle한 곳에서 backtrace 로그 출력 방식을 확인해보세요.
: 상황을 모르니 가정.. 프로세스는 화면에 로그를 뿌림. 테스트 단계에서는 동일한 shell에서 프로세스를 살리고 SIGSEGV를 전송했기 때문에 backtrace가 보임. 다만 crond에 의해 재시작 되면 shell이 달라서 화면에 로그 안보임.
: 관련 로그 및 backtrace를 파일에 적재하고 있다면 이 단계는 skip
2. 프로세스를 실행시키고 strace를 해당 pid에 걸어두고 일반 파일로 redirect 합니다. 나중에 redirect 파일을 확인해서 약간이나마 정보를 얻도록 합니다.
소곤소곤
답변 감사드립니다.
1. 스킵
2. 아래와 같이 실행하였는데
strace -Fftd -p 1042 -o strace_log.txt
별도로 시스템콜 필터링을 안해서 그런지
초당 2~3MB씩 쌓이더군요. 이부분 좀더 고민해 보겠습니다.
답변 정말 감사드립니다.
음 ..
코드 내에 setrlimit(RLIMIT_CORE, ..) 를 추가해서 항상 core 가 생성되도록 하고..
signal handler 에 backtrace() 를 넣어서 메시지를 파일로 저장하고 fflush() 호출..
저장 후에 exit() 로 빠지지 말고.. raise() 로 다시 시그널을 발생시켜서 정상적으로(?) 프로세스가 죽도록 하면 될 것 같네요.
만약 비정상 종료가 아닌 로직상 오류로 정상 종료하는 거라면 atexit() 나 on_exit() 로 체크 할 수 있을겁니다.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
답변 감사드립니다.
답변 감사드립니다.
-----------------------------------------------------------------------------------------
struct rlimit rlim;
int ret;
ret = getrlimit(RLIMIT_CORE,&rlim);
rlim.rlim_cur = RLIM_INFINITY;
printf("RLIMIT_CORE sft(%ld), hrd(%ld)\n", rlim.rlim_cur, rlim.rlim_max);
ret = setrlimit(RLIMIT_CORE, &rlim);
-----------------------------------------------------------------------------------------
# run programA
RLIMIT_CORE sft(-1), hrd(-1)
위와 같이 코드를 작성하였습니다. core dump 파일 생성또한 잘됩니다.
다만 궁금한점이 기존에도 core dump 파일은 생성되었기에 위와같이 설정을해주면
terminate + core dump 인 SIGSEGV 이 아닌
terminate만을 수행하는 SIGPIPE 경우에도 core dump를 생성하리라 기대 했는데 core dump를 생성하지는 않더군요.
이러한 시그널은 어떠한 방법으로도 core dump를 생성할수 없을까요?
signal handler의 경우
void * array[50];
int size = backtrace(array, 50);
array[1] = caller_address;
char ** messages = backtrace_symbols(array, size);
... back trace message LOG 파일에 출력
free(messages);
exit(EXIT_FAILURE);
이와 같이 작성되어있었는데
시그널을 다시 재발생시켜 정상적으로 (SIGKILL?) 죽게하는것과 그냥 죽게 하는것과 어떤 차이가 있는지 알수 있을까요?
음 ..
signal 의 default action 대신 handler 가 호출되었기 때문에, signal handler 에서 그냥 exit() 로 빠지면, 프로세스는 정상 종료한게 되어 버립니다.
default action 이 core 로 되어 있는 녀석 같은 경우는 core dump 를 할 수 있는 기회가 사라지게 되는거죠.
그래서 bactrace() 뜬 후에, 그냥 raise() 로 원래의 시그널을 다시 날려줘서 그 signal 의 default action 이 동작하게 해주면 낫다는거죠.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
감사합니다!
참고하여 SIG_DFL 정의후 raise()를 호출하니 말씀해주신대로 핸들러에서 일련의 작업들 수행후
본래 SIGNAL 동작을 수행하여 core dump 생성되는것 확인하였습니다.
많은 도움이 되었습니다. 감사합니다 ^^
댓글 달기