/ sys / kernel / debug / tracing의“cd”는 권한 변경을 유발합니다

나는 오늘 정말 이상한 문제에 직면했으며 그것에 대해 전혀 무기력합니다.

내가 관리하는 일부 서버는 Nagios로 모니터링됩니다. 최근 에이 오류로 디스크 사용 프로브가 실패하는 것을 보았습니다.

디스크 위험-/ sys / kernel / debug / tracing에 액세스 할 수 없음 : 권한 거부

조사하고 싶었고 첫 번째 시도는이 디렉토리 권한을 확인하고 다른 서버 (잘 작동하는)와 비교하는 것입니다. 다음은 작업 서버에서 실행 한 명령 이며 cd디렉토리에 들어가면 권한이 변경 되었음을 알 수 있습니다 .

# Here we've got 555 for /sys/kernel/debug/tracing
root@vps690079:/home/admin# cd /sys/kernel/debug
root@vps690079:/sys/kernel/debug# ll
total 0
drwx------ 30 root root 0 Jul 19 13:13 ./
drwxr-xr-x 13 root root 0 Jul 19 13:13 ../
…
dr-xr-xr-x  3 root root 0 Jul 19 13:13 tracing/
drwxr-xr-x  6 root root 0 Jul 19 13:13 usb/
drwxr-xr-x  2 root root 0 Jul 19 13:13 virtio-ports/
-r--r--r--  1 root root 0 Jul 19 13:13 wakeup_sources
drwxr-xr-x  2 root root 0 Jul 19 13:13 x86/
drwxr-xr-x  2 root root 0 Jul 19 13:13 zswap/

# I cd into the folder, and it (./) becomes 700!!
root@vps690079:/sys/kernel/debug# cd tracing/
root@vps690079:/sys/kernel/debug/tracing# ll
total 0
drwx------  8 root root 0 Jul 19 13:13 ./
drwx------ 30 root root 0 Jul 19 13:13 ../
-r--r--r--  1 root root 0 Jul 19 13:13 available_events
-r--r--r--  1 root root 0 Jul 19 13:13 available_filter_functions
-r--r--r--  1 root root 0 Jul 19 13:13 available_tracers
…

# Next commands are just a dumb test to double-check what I'm seeing
root@vps690079:/sys/kernel/debug/tracing# cd ..
root@vps690079:/sys/kernel/debug# ll
total 0
drwx------ 30 root root 0 Jul 19 13:13 ./
drwxr-xr-x 13 root root 0 Sep 27 10:57 ../
…
drwx------  8 root root 0 Jul 19 13:13 tracing/
drwxr-xr-x  6 root root 0 Jul 19 13:13 usb/
drwxr-xr-x  2 root root 0 Jul 19 13:13 virtio-ports/
-r--r--r--  1 root root 0 Jul 19 13:13 wakeup_sources
drwxr-xr-x  2 root root 0 Jul 19 13:13 x86/
drwxr-xr-x  2 root root 0 Jul 19 13:13 zswap/

이 동작의 원인이 무엇인지 알고 계십니까?
참고로 chmod를 사용하여 권한을 다시 설정해도 프로브를 수정하지 않는 것 같습니다.

/ sys

/sys은 sysfs현재 시스템 커널 및 하드웨어 구성을 반영하고 실제 디스크 공간을 사용하지 않는 메모리의 커널 구조에 대한 전체 가상보기입니다. 정상적인 방식으로 새 파일과 디렉토리를 쓸 수 없습니다.

디스크 공간 모니터링을 적용해도 유용한 정보가 생성되지 않으며 많은 노력이 필요합니다. 내부를 포함하여 다른 RAM 기반 가상 파일 시스템에 대한 마운트 지점이있을 수 있습니다 ...

/ sys / kernel / debug

/sys/kernel/debug의 표준 마운트 지점으로 debugfs, 다양한 커널 디버깅 및 추적 기능을위한 선택적 가상 파일 시스템입니다.

기능 디버깅을위한 것이기 때문에 프로덕션 용도로는 불필요해야합니다 (시스템 통계 또는 이와 유사한 기능을 위해 일부 기능을 사용하도록 선택할 수도 있음).

debugfs대부분의 경우 will에서 제공하는 기능을 사용하려면 root어쨌든 커널 개발자가 디버그 정보를 쉽게 제공 할 수 있도록하는 것이 주된 목적이므로 "가장 거친 부분"일 수 있습니다.

커널이로드되면 커널 추적 서브 시스템의 초기화 루틴이 /sys/kernel/debug/tracing자체적으로 debugfs 액세스 포인트로 등록 되어 실제로 처음으로 액세스 될 때까지 추가 초기화를 지연시킵니다 (추적 서브 시스템의 자원 사용이 최소화되는 경우 최소화 됨) 필요하지 않음). 당신이 때 cd디렉토리에 'D가이 연기 초기화가 트리거 된 추적 서브 시스템은 사용하기 위해 자신을 readied. 실제로 원본 /sys/kernel/debug/tracing은 처음에는 물질이없는 신기루였으며, cd명령으로 액세스 할 때 "실제"가되었습니다 .

debugfs 실제 디스크 공간을 전혀 사용하지 않습니다. 커널이 종료되면 그 안에 포함 된 모든 정보가 사라집니다.

/ sys / fs / cgroup

/sys/fs/cgroupA는 tmpfs로 그룹화 다양한 실행 프로세스에 사용되는 형 RAM 기반 파일 시스템 제어 그룹 . 실제 디스크 공간을 전혀 사용하지 않습니다. 그러나 어떤 이유로이 파일 시스템이 거의 가득 차면 디스크 공간이 부족한 것보다 더 심각 할 수 있습니다 .

a) 사용 가능한 RAM이 부족합니다.

b) 일부 루트 소유 프로세스가에 쓰레기를 /sys/fs/cgroup쓰거나

c) 무엇인가가 고전적인 "포크 폭탄"과 같은 방식으로 systemd기반 서비스 또는 이와 유사한 방식 으로 진정으로 터무니없는 수의 제어 그룹을 만들게 합니다.

결론

디스크에/sys 아무것도 /sys저장되어 있지 않기 때문에 디스크 사용 프로브를 제외 해야합니다 .

모니터링 /sys/fs/cgroup해야 할 경우 일반 디스크 공간 프로브보다 더 의미있는 경고를 제공하는 전용 프로브를 제공해야합니다.