/ Sys / kernel / debug / tracing içine “cd” izin değişikliğine neden olur

Bugün gerçekten garip bir sorunla karşılaştım ve bu konuda tamamen çaresizim.

Yönettiğim bazı sunucular Nagios ile izleniyor. Son zamanlarda bir disk kullanım probu bu hatayla başarısız gördüm:

DİSK KRİTİK - / sys / çekirdek / hata ayıklama / izleme erişilebilir değil: İzin reddedildi

Araştırmak istedim ve ilk denemem bu dizin izinlerini kontrol etmek ve bunları (kim iyi çalışıyor) başka bir sunucu ile karşılaştırmak oldu. İşte çalışma sunucusunda çalıştırdığım komutlar cdve dizine girer girmez izinlerinin değiştiğini göreceksiniz :

# 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/

Bu davranışa neyin sebep olabileceği hakkında bir fikriniz var mı?
Yan not, izinleri yeniden oluşturmak için chmod kullanmak probu düzeltiyor gibi görünmüyor.

/ sys

/sysolan sysfsmevcut sistem çekirdeği ve donanım konfigürasyonu yansıtır ve herhangi bir gerçek disk alanı tüketmez bellekte çekirdek yapılarına bütünüyle sanal görünümü. Yeni dosyalar ve dizinler normal şekilde yazılamaz.

Disk alanı izlemeyi uygulamak yararlı bilgiler üretmez ve zahmetsizdir. İçindeki diğer RAM tabanlı sanal dosya sistemleri için bağlama noktaları olabilir ...

/ Sys / kernel / debug

/sys/kernel/debugdebugfsçeşitli çekirdek hata ayıklama ve izleme özellikleri için isteğe bağlı bir sanal dosya sistemi olan standart bağlama noktasıdır .

Hata ayıklama özellikleri nedeniyle, üretim kullanımı için gereksiz olması gerekir (ancak bazı gelişmiş sistem istatistikleri veya benzeri özellikler için bazı özellikleri kullanmayı seçebilirsiniz).

debugfsÇoğu durumda irade tarafından sunulan özellikleri kullanmak rootyine de olmayı gerektirdiğinden ve asıl amacı, çekirdek geliştiricilerinin hata ayıklama bilgisi sağlamak için kolay bir yol olması olduğundan, biraz "kenarlarda pürüzlü" olabilir.

Çekirdek yüklendiğinde, /sys/kernel/debug/tracingkendisi için bir hata ayıklama erişim noktası olarak kaydedilen çekirdek izleme alt sistemi için başlatma yordamı , ilk kez erişilinceye kadar daha fazla başlatmayı erteler (izleme alt sisteminin kaynak durumunda kullanılması en aza indirgenir) gerekli değil). Size ne zaman cddizine 'd, bu ertelenmiş başlatma tetikleyip edildi izleme alt sistemi kullanmak için kendini hazır hale. Aslında, orijinal /sys/kernel/debug/tracingbaşlangıçta madde içermeyen bir seraptı ve sadece cdkomutunuzla eriştiğinizde (ve çünkü) "gerçek" oldu .

debugfs hiçbir gerçek disk alanı kullanmaz: İçindeki tüm bilgiler çekirdek kapatıldığında ortadan kaybolacaktır.

/ Sys / fs / CGroup

/sys/fs/cgroupa, tmpfsiçine grubu, çeşitli çalışma süreçleri için kullanılan tipi RAM tabanlı dosya sistemi, kontrol grubu . Gerçek disk alanı kullanmaz. Ancak bu dosya sistemi bir nedenden dolayı neredeyse doluysa, sadece disk alanınız tükenmekten daha ciddi olabilir:

a) boş RAM'iniz bittiğinde,

b) Bazı kök mülkiyetindeki süreç için çöp yazıyor /sys/fs/cgroupya

c) Muhtemelen klasik bir "çatal bombası" tarzında, ancak systemdtabanlı hizmetler veya benzeri bir şekilde, gerçekten saçma sayıda kontrol grubunun oluşturulmasına neden oluyor .

Sonuç olarak

/sysAltında hiçbir şey /sysherhangi bir diskte depolanmadığı için bir disk kullanım probu hariç tutulmalıdır.

İzlemeniz gerekiyorsa /sys/fs/cgroup, genel disk alanı probundan daha anlamlı uyarılar sağlayacak özel bir prob sağlamanız gerekir.