여러 시스템이 NFS를 통해 동일한 파일 시스템을 공유하는 설정이 있습니다. 대기열 시스템을 사용하면 처리 작업을 다양한 속성을 가진 여러 시스템에 제출할 수 있습니다.
때때로 작업이 중단되고 코어 파일(예: 이름)이 남습니다 core.1234
.
해당 코어 파일을 생성한 호스트를 찾는 방법이 있습니까? 호스트 이름은 무엇입니까?
(차이가 있는 경우 Linux 64비트에 적용됩니다.)
답변1
안에매우 낮은 주파수시스템에서 코어 파일은 거의 확실히 유효한 ELF 파일입니다.
$ readelf -a core
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: CORE (Core file)
Machine: Intel 80386
[...]
디버거가 해당 메서드를 찾을 수 있도록 플랫폼별 "설명" 수는 설명 섹션에 추가됩니다. 예를 들어 Solaris의 경우 참조코어(4)NT_UTSNAME
, 시스템 호출의 데이터 구조가 포함된 구조를 볼 수 있습니다 uname(2)
. elfdump -n
읽는 방식이지만, 제가 아는 한 Solaris는 이 작업을 수행하는 유일한 운영 체제입니다(Solaris 11만 elfdump
예상대로 작동한다고 생각합니다).
간단하지만 약간 지루하고 보장되지 않는 방법은 코어 덤프 환경에서 변수(일부 시작 스크립트 및 셸에 의해 설정됨, 적어도 설정됨) HOST
를 가져오려고 시도하는 것입니다. : 을 사용하여 이 작업을 수행할 수 있지만 원본 바이너리가 필요합니다.HOSTNAME
bash
HOSTNAME
gdb
$ gdb /usr/bin/sleep core
[... snip ...]
(gdb) print (char ***) &environ
$1 = (char ***) 0x600bf8
(gdb) print $1[0][0]@10
$2 = {0x7fffffffd9c9 "HOST=myhostname", 0x7fffffffd9d9 "TERM=screen",
0x7fffffffd9e5 "SHELL=/bin/csh",
[...]
이것environ
기호에서 문자열 덩어리를 인쇄합니다.. 이것은 끔찍한 해킹이지만 strings | grep HOSTNAME=
작동할 수도 있습니다.
그래서 짧은 대답은 "해당 코어 파일을 생성한 호스트를 찾는 방법이 있습니까?"Linux에서는 쉽지도 않고 신뢰할 수도 없습니다.
FWIW, Linux의 관련 코어 덤프 코드는 에 있으며 fs/binfmt_elf.c
다음을 통해 추가 "주석"을 허용하는 후크가 있습니다.ARCH_HAVE_EXTRA_ELF_NOTES
, 현재 PowerPC에서만 사용할 수 있습니다. )
더 나은 계획은sysctl을 사용하여 코어 파일 이름 설정@jlliagre가 제안한 대로 각 클라이언트에서 다음을 수행합니다.
sysctl kernel.core_pattern="%h-%t-%e.core"
( 여기서 sysctl
언급하는 내용은 동일하며 변경 사항이 기록될 수 있고 *BSD 시스템에서도 작동하기 때문에 /proc
선호합니다 .)sysctl
/etc/sysctl.conf
답변2
strings core.1234
실행하여 호스트 이름이 어딘가에 나타나는지 확인할 수 있습니다. 일부 운영 체제(예: Solaris)는 호스트 이름을 코어 헤더에 넣지만, 내가 아는 한 Linux에서는 이를 수행하지 않으므로 이 strings
방법은 신뢰할 수 없습니다.
더 나은 접근 방식은 설정 파일이나 일부 배포판별 구성(실행 파일을 참조하는 경우)을 통해 클라이언트를 구성하고 NFS
해당 호스트 이름을 코어 파일 이름에 넣는 것입니다./proc/sys/kernel/core_pattern
core_pattern