strace를 사용하여 소프트웨어 배포 디버깅

제가 하는 일은 대부분 소프트웨어 배포입니다. 즉, 다음과 같은 질문에 답변하는 데 많은 시간을 보냅니다.

• 이 소프트웨어는 개발자에게는 작동하지만 나에게는 작동하지 않습니다. 왜?
• 어제는 이 소프트웨어가 제게 효과가 있었지만 오늘은 그렇지 않습니다. 왜?

이는 일반적인 소프트웨어 디버깅과 약간 다른 일종의 디버깅입니다. 일반 디버깅은 코드의 논리에 관한 것이지만 배포 디버깅은 코드와 환경 간의 상호 작용에 관한 것입니다. 문제의 근본 원인이 논리적 오류인 경우에도 모든 것이 한 시스템에서는 작동하고 다른 시스템에서는 작동하지 않는다는 사실은 문제가 환경에 있다는 것을 의미합니다.

따라서 다음과 같은 일반적인 디버깅 도구 대신 gdb 배포 디버깅을 위한 다른 도구 세트가 있습니다. 그리고 "이 소프트웨어는 왜 나에게 작동하지 않나요?"와 같은 문제를 해결하기 위해 제가 가장 좋아하는 도구입니다. ~라고 불리는 추적하다.

스트레이스란 무엇인가요?

추적하다 "시스템 호출 추적"을 위한 도구입니다. 원래 Linux용으로 만들어졌지만 다른 시스템용 도구를 사용하여 동일한 디버깅 트릭을 수행할 수 있습니다(DTrace 또는 ktration).

기본 응용 프로그램은 매우 간단합니다. 아무 명령이나 사용하여 strace를 실행하면 모든 시스템 호출이 덤프됩니다(물론 먼저 직접 설치해야 할 수도 있음). 추적하다):

$ strace echo Hello
...Snip lots of stuff...
write(1, "Hellon", 6)                  = 6
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

이 시스템 호출은 무엇입니까? 이는 운영 체제 커널용 API와 비슷합니다. 옛날 옛적에는 소프트웨어가 실행되는 하드웨어에 직접 액세스할 수 있었습니다. 예를 들어 화면에 무언가를 표시해야 하는 경우 비디오 장치용 포트나 메모리 매핑된 레지스터를 사용하여 재생되었습니다. 멀티태스킹 컴퓨터 시스템이 대중화되자 다양한 응용 프로그램이 하드웨어를 두고 싸우면서 혼란이 닥쳤습니다. 한 응용 프로그램의 오류로 인해 전체 시스템은 아니더라도 다른 응용 프로그램이 중단될 수 있습니다. 그런 다음 권한 모드(또는 "링 보호")가 CPU에 나타났습니다. 커널은 가장 높은 권한을 갖게 되었습니다. 즉, 하드웨어에 대한 전체 액세스 권한을 얻었고 시스템 호출을 통해 하드웨어와 상호 작용하기 위해 이미 커널에 액세스를 요청해야 했던 권한이 낮은 응용 프로그램을 생성했습니다.

바이너리 수준에서 시스템 호출은 간단한 함수 호출과 약간 다르지만 대부분의 프로그램은 표준 라이브러리의 래퍼를 사용합니다. 저것들. POSIX C 표준 라이브러리에는 함수 호출이 포함되어 있습니다. 쓰다(), 시스템 호출에 대한 모든 아키텍처별 코드가 포함되어 있습니다. 쓰다.

간단히 말해서, 애플리케이션과 해당 환경(컴퓨터 시스템) 간의 모든 상호 작용은 시스템 호출을 통해 수행됩니다. 따라서 소프트웨어가 한 컴퓨터에서는 작동하지만 다른 컴퓨터에서는 작동하지 않는 경우 시스템 호출 추적 결과를 살펴보는 것이 좋습니다. 보다 구체적으로 다음은 시스템 호출 추적을 사용하여 분석할 수 있는 일반적인 사항 목록입니다.

• 콘솔 I/O
• 네트워크 I/O
• 파일 시스템 액세스 및 파일 I/O
• 프로세스 스레드의 수명 관리
• 낮은 수준의 메모리 관리
• 특정 장치 드라이버에 액세스

언제 strace를 사용하나요?

이론에 의하면, 추적하다 사용자 공간의 모든 프로그램은 시스템 호출을 해야 하기 때문에 사용자 공간의 모든 프로그램과 함께 사용됩니다. 컴파일된 저수준 프로그램에서 더 효율적으로 작동하지만, 런타임과 인터프리터에서 발생하는 추가적인 소음을 줄일 수 있다면 Python과 같은 고급 언어에서도 작동합니다.

모든 화려함 속에서 추적하다 한 컴퓨터에서는 잘 작동하지만 다른 컴퓨터에서는 갑자기 작동을 멈추는 소프트웨어를 디버깅하는 동안 나타납니다. 파일, 권한 또는 일부 명령이나 다른 것을 실행하려는 실패한 시도에 대한 모호한 메시지가 생성됩니다... 안타깝지만 그렇지 않습니다. 인증서 확인 오류와 같은 높은 수준의 문제와 잘 결합됩니다. 일반적으로 이를 위해서는 조합이 필요합니다. 추적하다때때로 추적 더 높은 수준의 도구(명령줄 도구 등) 하려면 openssl 인증서를 디버그하기 위해).

예제에서는 독립 실행형 서버를 사용하지만 시스템 호출 추적은 더 복잡한 배포 플랫폼에서 수행될 수 있는 경우가 많습니다. 올바른 도구를 선택하기만 하면 됩니다.

간단한 디버깅 예제

놀라운 서버 애플리케이션인 foo를 실행하고 싶다고 가정해 보겠습니다. 결과는 다음과 같습니다.

$ foo
Error opening configuration file: No such file or directory

분명히 당신이 작성한 구성 파일을 찾을 수 없습니다. 이는 때때로 패키지 관리자가 애플리케이션을 컴파일할 때 예상 파일 위치를 재정의하기 때문에 발생합니다. 그리고 한 배포판의 설치 가이드를 따르면 다른 배포판에서는 예상했던 것과 완전히 다른 파일을 발견하게 됩니다. 오류 메시지에 구성 파일을 찾을 위치가 표시되면 몇 초 안에 문제가 해결될 수 있지만 그렇지 않습니다. 그럼 어디를 봐야 할까요?

소스 코드에 접근할 수 있다면 그것을 읽고 모든 것을 알아낼 수 있습니다. 좋은 백업 계획이지만 가장 빠른 솔루션은 아닙니다. 다음과 같은 단계별 디버거를 사용할 수 있습니다. gdb 프로그램이 무엇을 하는지 살펴보세요. 그러나 환경과의 상호 작용을 보여주기 위해 특별히 설계된 도구를 사용하는 것이 훨씬 더 효과적입니다. 추적하다.

출력 추적하다 중복되어 보일 수 있지만 좋은 소식은 대부분을 무시해도 된다는 것입니다. 추적 결과를 별도의 파일에 저장하려면 -o 연산자를 사용하는 것이 유용한 경우가 많습니다.

$ strace -o /tmp/trace foo
Error opening configuration file: No such file or directory
$ cat /tmp/trace
execve("foo", ["foo"], 0x7ffce98dc010 /* 16 vars */) = 0
brk(NULL)                               = 0x56363b3fb000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=25186, ...}) = 0
mmap(NULL, 25186, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2f12cf1000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "177ELF2113 3 > 1 260A2 "..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1824496, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2f12cef000
mmap(NULL, 1837056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2f12b2e000
mprotect(0x7f2f12b50000, 1658880, PROT_NONE) = 0
mmap(0x7f2f12b50000, 1343488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f2f12b50000
mmap(0x7f2f12c98000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16a000) = 0x7f2f12c98000
mmap(0x7f2f12ce5000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b6000) = 0x7f2f12ce5000
mmap(0x7f2f12ceb000, 14336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2f12ceb000
close(3)                                = 0
arch_prctl(ARCH_SET_FS, 0x7f2f12cf0500) = 0
mprotect(0x7f2f12ce5000, 16384, PROT_READ) = 0
mprotect(0x56363b08b000, 4096, PROT_READ) = 0
mprotect(0x7f2f12d1f000, 4096, PROT_READ) = 0
munmap(0x7f2f12cf1000, 25186)           = 0
openat(AT_FDCWD, "/etc/foo/config.json", O_RDONLY) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
brk(NULL)                               = 0x56363b3fb000
brk(0x56363b41c000)                     = 0x56363b41c000
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x8), ...}) = 0
write(3, "Error opening configuration file"..., 60) = 60
close(3)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

대략 출력 첫 번째 페이지 전체 추적하다 - 이는 일반적으로 출시를 위한 낮은 수준의 준비입니다. (전화가 많이 와요. mmap, 엠프로텍트, BRK 낮은 수준의 메모리 감지 및 동적 라이브러리 표시와 같은 작업에 사용됩니다.) 실제로 출력을 디버깅하는 동안 추적하다 맨 끝부터 읽는 것이 좋습니다. 아래에 챌린지가 있습니다. 쓰다, 오류 메시지가 표시됩니다. 위를 보면 첫 번째 잘못된 시스템 호출인 호출이 보입니다. 열기, 오류가 발생합니다. 에노엔트 ("파일 또는 디렉터리를 찾을 수 없습니다.") 열려고 하는 중 /etc/foo/config.json. 여기에 구성 파일이 있어야 합니다.

이것은 단지 예일 뿐이지만 제가 사용하는 시간의 90%는 다음과 같습니다. 추적하다, 이것보다 더 어려운 일은 없습니다. 다음은 완전한 단계별 디버깅 가이드입니다.

• 프로그램의 시스템 오류에 대한 모호한 메시지 때문에 화를 냅니다.
• 다음으로 프로그램을 다시 시작하세요. 추적하다
• 추적 결과에서 오류 메시지 찾기
• 첫 번째 실패한 시스템 호출이 발생할 때까지 더 높이 올라갑니다.

4단계의 시스템 호출을 통해 무엇이 잘못되었는지 밝혀질 가능성이 매우 높습니다.

팁

보다 복잡한 디버깅의 예를 보여주기 전에 효과적인 사용을 위한 몇 가지 요령을 보여 드리겠습니다. 추적하다:

남자는 네 친구야

많은 *nix 시스템에서 커널에 대한 전체 시스템 호출 목록은 다음을 실행하여 얻을 수 있습니다. 남자 시스템콜. 다음과 같은 내용이 표시됩니다. brk(2)이는 다음을 실행하여 더 많은 정보를 얻을 수 있음을 의미합니다. 남자 2brk.

작은 갈퀴: 남자 2 포크 쉘 페이지를 보여줍니다 포크() в GNU libc, 이는 다음을 호출하여 구현되는 것으로 나타났습니다. clone (). 호출 의미론 포크 다음을 사용하여 프로그램을 작성하면 동일하게 유지됩니다. 포크(), 추적을 실행합니다. 전화를 찾을 수 없습니다. 포크, 그 대신에 clone (). 이러한 갈퀴는 소스와 출력을 비교하기 시작하는 경우에만 혼란을 줍니다. 추적하다.

-o를 사용하여 출력을 파일에 저장합니다.

추적하다 광범위한 출력을 생성할 수 있으므로 추적 결과를 별도의 파일에 저장하는 것이 유용한 경우가 많습니다(위의 예 참조). 이는 또한 프로그램 출력과 출력의 혼동을 방지하는 데 도움이 됩니다. 추적하다 콘솔에서.

더 많은 인수 데이터를 보려면 -s를 사용하세요.

위의 예제 추적에는 오류 메시지의 후반부가 표시되지 않은 것을 알 수 있습니다. 왜냐하면 추적하다 기본값은 문자열 인수의 처음 32바이트만 표시합니다. 더 보고 싶다면 다음과 같이 추가하세요. -s 128 전화에 추적하다.

-y를 사용하면 파일, 소켓 등을 더 쉽게 추적할 수 있습니다.

"All is file"은 *nix 시스템이 파일, 네트워크 또는 프로세스 간 파이프에 적용되는지 여부에 관계없이 파일 설명자를 사용하여 모든 I/O를 수행한다는 것을 의미합니다. 이는 프로그래밍에는 편리하지만 일반적인 내용을 보면 실제로 무슨 일이 일어나고 있는지 추적하기가 어렵습니다. 읽기 и 쓰다 시스템 호출 추적 결과에서.

연산자를 추가하여 y, 당신은 강제로 추적하다 출력의 각 파일 설명자에 그것이 가리키는 내용을 기록해 주석을 답니다.

-p**를 사용하여 이미 실행 중인 프로세스에 연결

아래 예에서 볼 수 있듯이 때로는 이미 실행 중인 프로그램을 추적해야 할 때가 있습니다. 프로세스 1337로 실행되고 있는 것으로 알려진 경우(예: 출력에서 ps), 다음과 같이 추적할 수 있습니다.

$ strace -p 1337
...system call trace output...

루트 권한이 필요할 수 있습니다.

하위 프로세스를 모니터링하려면 -f를 사용하세요.

추적하다 기본적으로 하나의 프로세스만 추적합니다. 이 프로세스가 하위 프로세스를 생성하는 경우 하위 프로세스를 생성하는 시스템 호출을 볼 수 있지만 하위 프로세스의 시스템 호출은 표시되지 않습니다.

오류가 하위 프로세스에 있다고 생각되면 다음 명령문을 사용하십시오. -f, 그러면 추적이 활성화됩니다. 이것의 단점은 출력이 당신을 더욱 혼란스럽게 할 것이라는 점입니다. 언제 추적하다 하나의 프로세스나 하나의 스레드를 추적하면 호출 이벤트의 단일 스트림이 표시됩니다. 한 번에 여러 프로세스를 추적할 때 메시지로 인해 호출이 중단되는 것을 볼 수 있습니다. , 그런 다음 - 다른 실행 분기에 대한 여러 호출, 그리고 나서야 - 첫 번째 분기의 끝 <…푸콜 재개>. 또는 연산자를 사용하여 모든 추적 결과를 다른 파일로 분할합니다. -ff (자세한 내용은 안내서 에 추적하다).

-e를 사용하여 추적 필터링

보시다시피 추적 결과는 가능한 모든 시스템 호출의 실제 더미입니다. 깃발 -e 추적을 필터링할 수 있습니다(참조: 지도력 에 추적하다). 가장 큰 장점은 전체 추적을 수행한 다음 필터링된 추적을 실행하는 것보다 더 빠르다는 것입니다. GREP`에. 솔직히 말해서 나는 거의 항상 신경 쓰지 않습니다.

모든 실수가 나쁜 것은 아니다

간단하고 일반적인 예는 실행 파일이 포함된 디렉터리를 찾는 셸과 같이 한 번에 여러 위치에서 파일을 찾는 프로그램입니다.

$ strace sh -c uname
...
stat("/home/user/bin/uname", 0x7ffceb817820) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/uname", 0x7ffceb817820) = -1 ENOENT (No such file or directory)
stat("/usr/bin/uname", {st_mode=S_IFREG|0755, st_size=39584, ...}) = 0
...

"오류를 보고하기 전 마지막으로 실패한 요청"과 같은 경험적 방법은 관련 오류를 찾는 데 좋습니다. 그렇더라도 맨 끝부터 시작하는 것이 논리적입니다.

C 프로그래밍 튜토리얼은 시스템 호출을 이해하는 데 도움이 될 수 있습니다.

C 라이브러리에 대한 표준 호출은 시스템 호출이 아니라 얇은 표면 계층일 뿐입니다. 따라서 C에서 수행하는 방법과 작업을 조금이라도 이해하면 시스템 호출 추적 결과를 이해하기가 더 쉬울 것입니다. 예를 들어, 네트워크 시스템에 대한 호출을 디버깅하는 데 문제가 있는 경우 동일한 클래식 Bija의 네트워크 프로그래밍 가이드.

더 복잡한 디버깅 예제

간단한 디버깅의 예는 제가 작업할 때 주로 다뤄야 할 일의 예라고 이미 말씀드렸습니다. 추적하다. 그러나 실제 조사가 필요한 경우도 있으므로 다음은 고급 디버깅의 실제 예입니다.

브론 - 작업 처리 스케줄러, *nix 데몬의 또 다른 구현 크론. 서버에 설치되어 있지만 누군가 일정을 편집하려고 하면 다음과 같은 일이 발생합니다.

# crontab -e -u logs
bcrontab: Fatal: Could not create temporary file

알았어, 그 말은 브론 특정 파일을 작성하려고 했지만 작동하지 않았고 그 이유를 인정하지 않았습니다. 발견 추적하다:

# strace -o /tmp/trace crontab -e -u logs
bcrontab: Fatal: Could not create temporary file
# cat /tmp/trace
...
openat(AT_FDCWD, "bcrontab.14779.1573691864.847933", O_RDONLY) = 3
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f82049b4000
read(3, "#Ansible: logsaggn20 14 * * * lo"..., 8192) = 150
read(3, "", 8192)                       = 0
munmap(0x7f82049b4000, 8192)            = 0
close(3)                                = 0
socket(AF_UNIX, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/bcron-spool"}, 110) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f82049b4000
write(3, "156:Slogs #Ansible: logsaggn20 1"..., 161) = 161
read(3, "32:ZCould not create temporary f"..., 8192) = 36
munmap(0x7f82049b4000, 8192)            = 0
close(3)                                = 0
write(2, "bcrontab: Fatal: Could not creat"..., 49) = 49
unlink("bcrontab.14779.1573691864.847933") = 0
exit_group(111)                         = ?
+++ exited with 111 +++

마지막 부분에 오류 메시지가 있습니다. 쓰다, 하지만 이번에는 뭔가 다릅니다. 첫째, 일반적으로 이 전에 발생하는 관련 시스템 호출 오류가 없습니다. 둘째, 누군가가 이미 오류 메시지를 읽었음이 분명합니다. 진짜 문제는 다른 데 있는 것 같은데, 브론탭 단순히 메시지를 재생합니다.

보니 남자 2 읽다, 첫 번째 인수(3)는 *nix가 모든 I/O 처리에 사용하는 파일 설명자임을 알 수 있습니다. 파일 설명자 3이 무엇을 나타내는지 어떻게 알 수 있나요? 이 특별한 경우에는 다음을 실행할 수 있습니다. 추적하다 с 작업 y (위 참조) 자동으로 알려 주지만 이와 같은 내용을 파악하려면 추적 결과를 읽고 구문 분석하는 방법을 아는 것이 유용합니다.

파일 설명자의 소스는 많은 시스템 호출 중 하나일 수 있습니다(모두 설명자의 용도에 따라 다름 - 콘솔, 네트워크 소켓, 파일 자체 또는 기타). 그러나 그럴 수도 있으므로 우리는 다음을 찾습니다. 3을 반환하여 호출합니다(즉, 추적 결과에서 "= 3"을 찾습니다). 이 결과에는 2가지가 있습니다. 열기 맨 꼭대기에 그리고 소켓 중간에. 열기 파일을 열지만 가까운(3)은 다시 닫히는 것을 보여줍니다. (Rake: 파일 설명자를 열고 닫을 때 재사용할 수 있습니다.) 부르다 소켓() 전 마지막이니까 적당해 읽다(), bcrontab은 소켓을 통해 무언가와 작동하는 것으로 나타났습니다. 다음 줄은 파일 설명자가 다음과 연관되어 있음을 보여줍니다. 유닉스 도메인 소켓 도중에 /var/run/bcron-스풀.

따라서 우리는 다음과 관련된 프로세스를 찾아야 합니다. 유닉스 소켓 반대편에. 이 목적을 위한 몇 가지 유용한 방법이 있으며 둘 다 서버 배포 디버깅에 유용합니다. 첫 번째는 사용하는 것입니다. NETSTAT 또는 최신 ss (소켓 상태). 두 명령 모두 시스템의 활성 네트워크 연결을 표시하고 다음 명령문을 사용합니다. -l 청취 소켓과 연산자를 설명하기 위해 -p 클라이언트로 소켓에 연결된 프로그램을 표시합니다. (더 많은 유용한 옵션이 있지만 이 작업에는 이 두 가지만으로 충분합니다.)

# ss -pl | grep /var/run/bcron-spool
u_str LISTEN 0   128   /var/run/bcron-spool 1466637   * 0   users:(("unixserver",pid=20629,fd=3))

이는 청취자가 명령임을 나타냅니다. inix서버, 프로세스 ID 20629로 실행 중입니다. (그리고 공교롭게도 파일 설명자 3을 소켓으로 사용합니다.)

동일한 정보를 찾는 데 정말 유용한 두 번째 도구는 이소프. 시스템에 열려 있는 모든 파일(또는 파일 설명자)이 나열됩니다. 또는 하나의 특정 파일에 대한 정보를 얻을 수 있습니다.

# lsof /var/run/bcron-spool
COMMAND   PID   USER  FD  TYPE  DEVICE              SIZE/OFF  NODE    NAME
unixserve 20629 cron  3u  unix  0x000000005ac4bd83  0t0       1466637 /var/run/bcron-spool type=STREAM

프로세스 20629는 수명이 긴 서버이므로 다음에 연결할 수 있습니다. 추적하다 다음과 같은 것을 사용하여 strace -o /tmp/추적 -p 20629. 다른 터미널에서 cron 작업을 편집하면 오류가 있는 추적 출력을 받게 됩니다. 결과는 다음과 같습니다.

accept(3, NULL, NULL)                   = 4
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21181
close(4)                                = 0
accept(3, NULL, NULL)                   = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21181, si_uid=998, si_status=0, si_utime=0, si_stime=0} ---
wait4(0, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED, NULL) = 21181
wait4(0, 0x7ffe6bc36764, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
rt_sigaction(SIGCHLD, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, 8) = 0
rt_sigreturn({mask=[]})                 = 43
accept(3, NULL, NULL)                   = 4
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21200
close(4)                                = 0
accept(3, NULL, NULL)                   = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21200, si_uid=998, si_status=111, si_utime=0, si_stime=0} ---
wait4(0, [{WIFEXITED(s) && WEXITSTATUS(s) == 111}], WNOHANG|WSTOPPED, NULL) = 21200
wait4(0, 0x7ffe6bc36764, WNOHANG|WSTOPPED, NULL) = -1 ECHILD (No child processes)
rt_sigaction(SIGCHLD, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, {sa_handler=0x55d244bdb690, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7faa47ab9840}, 8) = 0
rt_sigreturn({mask=[]})                 = 43
accept(3, NULL, NULL

(마지막 수용하다() 추적 시 완료되지 않습니다.) 안타깝게도 이 결과에는 우리가 찾고 있는 오류가 포함되어 있지 않습니다. bcrontag가 소켓으로 보내거나 소켓에서 받는 메시지는 표시되지 않습니다. 대신 완전한 프로세스 제어(복제, 기다림4, SIGCHLD 등) 이 프로세스는 짐작할 수 있듯이 실제 작업을 수행하는 하위 프로세스를 생성합니다. 그리고 그녀의 흔적을 따라잡아야 한다면 통화에 추가하세요 추적 -f. 이것은 strace를 사용하여 새 결과에서 오류 메시지를 검색할 때 찾을 수 있는 것입니다. -f -o /tmp/추적 -p 20629:

21470 openat(AT_FDCWD, "tmp/spool.21470.1573692319.854640", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
21470 write(1, "32:ZCould not create temporary f"..., 36) = 36
21470 write(2, "bcron-spool[21470]: Fatal: logs:"..., 84) = 84
21470 unlink("tmp/spool.21470.1573692319.854640") = -1 ENOENT (No such file or directory)
21470 exit_group(111)                   = ?
21470 +++ exited with 111 +++

자, 그게 뭔가요. 경로에 파일을 생성하려고 하면 프로세스 21470에서 "액세스 거부" 오류가 발생합니다. tmp/spool.21470.1573692319.854640 (현재 작업 디렉토리와 관련됨) 현재 작업 디렉토리만 알고 있다면 전체 경로도 알고 프로세스가 해당 디렉토리에 임시 파일을 생성할 수 없는 이유를 알아낼 수 있습니다. 아쉽게도 프로세스가 이미 종료되었기 때문에 그냥 사용할 수는 없습니다. lsof -p 21470 현재 디렉터리를 찾으려면 반대 방향으로 작업할 수도 있습니다. 디렉터리를 변경하는 PID 21470 시스템 호출을 찾으세요. (아무것도 없으면 PID 21470은 부모로부터 상속받았음에 틀림없으며 이는 이미 완료되었습니다. lsof -p 찾을 수 없습니다.) 이 시스템 호출은 chdir (최신 온라인 검색 엔진의 도움으로 쉽게 찾을 수 있습니다). 다음은 추적 결과를 기반으로 서버 PID 20629까지 역방향 검색한 결과입니다.

20629 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7faa47c44810) = 21470
...
21470 execve("/usr/sbin/bcron-spool", ["bcron-spool"], 0x55d2460807e0 /* 27 vars */) = 0
...
21470 chdir("/var/spool/cron")          = 0
...
21470 openat(AT_FDCWD, "tmp/spool.21470.1573692319.854640", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
21470 write(1, "32:ZCould not create temporary f"..., 36) = 36
21470 write(2, "bcron-spool[21470]: Fatal: logs:"..., 84) = 84
21470 unlink("tmp/spool.21470.1573692319.854640") = -1 ENOENT (No such file or directory)
21470 exit_group(111)                   = ?
21470 +++ exited with 111 +++

(길을 잃으신 분들은 이전 포스팅을 읽어보시면 좋을 것 같습니다. *nix 프로세스 관리 및 쉘 정보.) 따라서 서버 PID 20629는 해당 경로에 파일을 생성할 수 있는 권한을 받지 못했습니다. /var/spool/cron/tmp/spool.21470.1573692319.854640. 아마도 그 이유는 클래식 파일 시스템 권한 설정 때문일 것입니다. 점검 해보자:

# ls -ld /var/spool/cron/tmp/
drwxr-xr-x 2 root root 4096 Nov  6 05:33 /var/spool/cron/tmp/
# ps u -p 20629
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cron     20629  0.0  0.0   2276   752 ?        Ss   Nov14   0:00 unixserver -U /var/run/bcron-spool -- bcron-spool

개가 묻혀 있는 곳이에요! 서버는 사용자 cron으로 실행되지만 루트만 디렉토리에 쓸 수 있는 권한이 있습니다. /var/spool/cron/tmp/. 간단한 명령 chown cron /var/spool/cron/tmp/ 할 것 브론 올바르게 작동하십시오. (만약 그것이 문제가 아니었다면 다음으로 의심되는 것은 SELinux 또는 AppArmor와 같은 커널 보안 모듈이므로 다음으로 커널 메시지 로그를 확인하겠습니다. dmesg에.)

전체로

시스템 호출 추적은 초보자에게 부담스러울 수 있지만 이것이 일반적인 배포 문제 전체를 디버그하는 빠른 방법이라는 점을 보여주었기를 바랍니다. 다중 프로세스를 디버깅하려고 한다고 상상해 보세요. 브론단계별 디버거를 사용합니다.

일련의 시스템 호출을 따라 역방향으로 추적 결과를 구문 분석하려면 기술이 필요하지만 앞서 말했듯이 거의 항상 다음을 사용합니다. 추적하다, 추적 결과를 얻고 끝부터 오류를 찾습니다. 그래도, 추적하다 디버깅에 많은 시간을 절약하는 데 도움이 됩니다. 나는 그것이 당신에게도 유용할 것이기를 바랍니다.

출처 : habr.com