잠그고 SIGKILL을 무시하는 프로세스는 실행할 수 있습니다 (좀비가 없거나 중단 할 수없는 절전 모드가 아님). 어떤 주에 있습니까?


17

여러 번 응답을 멈 췄고 완전히 잠긴 것처럼 보이는 프로세스가 있습니다. gdb를 사용하여 strace 또는 peeking 시도에 응답하지 않습니다 (gdb는 wait4 () syscall에 중단됩니다). 프로세스가 실행 가능하며 syscall (/ proc / X / syscall :) running또는 인터럽트 불가능 휴면 (/ proc / X / status :)에서 대기하지 않습니다 State: R (running).

이 과정은 정확히 어떤 상태입니까? 이것은 아마도 어떤 유형의 커널 버그입니까?

그 과정은 재발견되었으며, 지금은 몇 차례 일어났습니다. 프로세스를 죽일 수있는 것은 재부팅입니다. OS는 Cent 7입니다.

편집 : 커널 버전은 3.10.0-123.13.2.el7.x86_64입니다. 3.10.0-229.11.1.el7로 업데이트하여 차이가 있는지 확인하십시오.


어떤 버전의 GDB를 사용하고 있습니까? stackoverflow.com/questions/8978777/… 에 따르면 최신 버전이 더 잘 작동 할 수 있습니다.
Greg Bray 1

현재는 특별한 방식으로 조사가 커널 측에 더 많은 것처럼 보이지만, 마음에 들지 않으면 몇 가지 Redis 관련 정보를 추가 할 수 있습니까? 프로세스가 차단되는 동안 수행하는 작업 및 이와 유사한 작업 트위터를 통해 Nick Craver에서 몇 가지 정보를 얻었습니다.이 경우 Redis가 큰 데이터 세트를로드하고 있습니다. 데이터 세트가 프로세스를 다시 시작하거나 다른 방법 (예 : DEBUG RELOAD를 통해로드하거나 대량의 데이터를 파이프 라인으로로드) )? 감사.

@antirez 데이터 세트가 다른 redis 인스턴스의 rdb 사본에 의해로드되고 있습니다. 잠금은 redis가 시작되고 거대한 rdb에서 읽은 후에 발생합니다. 특히이 과정에서 항상 잠기는 것은 아닙니다.
외계인

1
IO 오류가 발생했을 때 이런 종류의 문제 만있었습니다. dmesg출력 에 대해 말씀해 주 시겠습니까?
Ho1

3
무엇 않습니다 /proc/<pid>/stack(그리고 /proc/<pid>/task/*/stack)를 포함? 해당 프로세스에 여러 스레드가 있습니까?
Stéphane Chazelas

답변:


2

wait4는 프로세스가 그의 자식 종료 중 하나를 기다리고 있음을 나타내는 syscall입니다. 신호 처리에 문제가있을 수 있습니다.

약간 잔인하지만 앱 의 계층 구조 를 종료 하려고 할 수 있습니다 kill -15 -$YourRedisPID. PID 앞 의 - 는 "PID 및 해당 자식"을 의미합니다. 아동 해고를 기다리는 것처럼 보이므로 잠금을 해제 할 수 있습니다.

작동하지 않으면 더 자세히 살펴 보겠습니다. grep ^Sig /proc/$YourRedisPID/status

다음과 같은 내용이 표시됩니다.

SigQ:   8/62777
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000080
SigCgt: 0000000180004023

커널 소스의 "fs / proc / array.c"에 정의 된 "SigQ"는 보류중인 신호 수 / 보류중인 신호의 한계입니다.

신호 수가 너무 많으면 "SIGKILL"이 전혀 처리되지 않았 음을 나타낼 수 있습니다. 이 특수 신호의 신호 관리를 이해하기 위해 여전히 "kernel / signal.c"파일을 확인하고 있습니다.

출력에 대한 직접적인 이해를 위해 다음 1 줄짜리 시도하십시오. awk 'BEGIN{print "ibase=16;obase=2;"} /^Sig...:/{ print toupper($2)}' /proc/$YourRedisPID/status | BC_LINE_LENGTH=0 bc

이것은 나를 출력합니다 :

0
0
10000000
110000000000000000100000000100011

이 출력을 보내서 시작하겠습니다. 필요에 따라 게시물을 업데이트하겠습니다.


프로세스가 wait4 ()에 있지 않고 프로세스에 액세스하려고 할 때 gdb가 wait4 ()에 정지됩니다. 프로세스 자체는 syscall에 없습니다. 또한 중단 된 프로세스에는 자식이 없습니다. 불행히도 나는 상자를 재부팅해야했습니다. 문제가 다시 발생하면 요청한 데이터를 수집하겠습니다.
외계인

여기에 출력 : gist.githubusercontent.com/alienth/23685ad2ea46a7eade56/raw/… 다시 한 번 proc이 SIGKILL을 무시합니다. syscall에 없습니다. Proc도 SIGTERM을 무시합니다.
외계인
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.