/proc fayl tizimi: kernel bilan to'g'ridan-to'g'ri muloqot

Shu modulda ko'rib chiqilgan deyarli har bir vosita — ps, top, nice, renice, hatto kill ning jarayon mavjudligini tekshirishi ham — oxir-oqibat bitta umumiy manbadan o'qiydi yoki unga yozadi. ps aux dagi RSS aslida qayerdan keladi? top dagi NI ustunini nima hisoblaydi? lsof jarayonning ochiq fayl deskriptorlarini ro'yxatlashi uchun kernel ularni qanday ko'rsatadi? Bu savollarning hammasiga javob bitta: /proc — kernel va jarayonlarning jonli holatini oddiy fayl va kataloglar ko'rinishida taqdim etadigan, diskdan o'qilmasdan, so'ralgan paytda yaratiladigan virtual fayl tizimi.

Bu maqola modulning yakunlovchi qismi: u avvalgi har bir maqoladagi raqamlar aslida qayerda turishini, ularni hech qanday oraliq vositasiz qanday to'g'ridan-to'g'ri o'qishni va nega /proc ni tushunish sizni shunchaki buyruq ishga tushiradigan odamdan mavjud birorta vosita qamrab olmaydigan vaziyatlarni tekshira oladigan, ular ustida skript yoza oladigan va debug qila oladigan mutaxassisga aylantirishini ko'rsatadi.

/proc haqiqiy fayl tizimi emas

/proc oddiy kataloglar daraxtiga o'xshaydi, lekin uning ichidagi hech narsa diskda mavjud emas. Bu psevdo fayl tizimi (pseudo-filesystem): kernel har bir fayl mazmunini aynan o'qilgan paytda yaratadi va u tizimning o'sha lahzadagi jonli holatini aks ettiradi. Xuddi shunday, /proc ostidagi ayrim fayllarga yozish kernel xatti-harakatini qayta yuklashsiz yoki xizmatni qayta ishga tushirmasdan darhol o'zgartiradi.

mount | grep '^proc'

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

/proc ostidagi fayl uchun ls -l odatda mazmuni o'qishda hisoblanadigan fayllar hajmini 0 deb ko'rsatadi, chunki oldindan aytib beriladigan qat’iy baytlar soni yo'q. Bu oddiy fayl bilan ishlamayotganingizni bildiradigan kichik, lekin ishonchli belgi.

Har bir jarayon uchun kataloglar: /proc/[pid]

Har bir ishlab turgan jarayonning o'z PID i bilan nomlangan alohida katalogi bor:

ls /proc/$$

$$ joriy shell’ning o'z PID iga aylanadi. Namunaviy (qisqartirilgan) ro'yxat:

cmdline  cwd  environ  exe  fd  limits  maps  mounts  net  root  smaps  stat  statm  status  task

status: odam o'qishi uchun qulay xulosa

cat /proc/$$/status | head -15

Name:   bash
State:  S (sleeping)
Tgid:   3990
Pid:    3990
PPid:   3821
Uid:    1000    1000    1000    1000
Gid:    1000    1000    1000    1000
VmSize:    23412 kB
VmRSS:      5120 kB
Threads:    1

Uid/Gid har biri to'rtta qiymatni ko'rsatadi — real, effective, saved-set va filesystem. Bu jarayon credential’lari mavzusida ko'rilgan o'sha farqlar. Bu yerda real va effective qiymatlar o'rtasidagi nomuvofiqlik (masalan, sudo bilan ko'tarilgan buyruq paytida) aynan id va ps -o ruser,user qulayroq ko'rinishda umumlashtiradigan narsa. VmRSS — Jarayon xotirasi maqolasida ps chiqishidagi RSS sifatida ko'rilgan aynan o'sha qiymat: ps shunchaki shu maydonni siz uchun o'qib beradi.

stat va statm: dastur o'qishi uchun ko'rinish

cat /proc/$$/stat

3990 (bash) S 3821 3990 3990 34816 4021 4194560 3421 891 0 0 12 4 0 0 20 0 1 0 8821 23977984 1280 ...

Bo'sh joy bilan ajratilgan bu bitta qatorni ps va top o'z ustunlarini qurish uchun aynan tahlil qiladi: 3-maydon holat belgisi (bu yerda S, ps dagi STAT ga mos keladi), 4-maydon PPID, 18-maydon (bu parchada 20) esa nice asosida yotgan xom priority qiymati. Kundalik ishda bu faylni to'g'ridan-to'g'ri o'qish kamdan-kam kerak bo'ladi, lekin uning mavjudligini bilish har bir jarayon kuzatish vositasi o'z raqamlarini qanday olishini tushunarli qiladi: ularning hech birida sizda yo'q maxsus kirish huquqi yo'q, hammasi bitta ochiq interfeysdan o'qiydi.

cmdline, cwd, exe: jarayon aslida nima ekanini aniqlash

cat /proc/$$/cmdline | tr '\0' ' '; echo
readlink /proc/$$/cwd
readlink /proc/$$/exe

-bash 
/home/ali
/usr/bin/bash

cmdline argumentlarini bo'sh joy bilan emas, null baytlar bilan ajratadi (bu yerda o'qishga qulay bo'lishi uchun tr bilan almashtirilgan). Shu sababli bitta argumentida bo'sh joy bo'lgan buyruq ham bu faylni to'g'ri tahlil qiladigan vositalarda to'g'ri ko'rinadi — ps ning formatlangan matn chiqishini bo'sh joylar bo'yicha sodda bo'lish esa bunday natija bermaydi. exe — shu jarayon ortida turgan haqiqiy binary faylga symlink. U ishlab turgan jarayon aynan qaysi fayldan va qaysi yo'ldan ishga tushirilganini tasdiqlash uchun foydali, ayniqsa paket yangilanishi diskdagi faylni almashtirgan, lekin eski jarayon (Dasturlar va jarayonlar maqolasidagi izohga ko'ra) hali ham oldingi versiyani ishlatayotgan holatda.

fd: har bir ochiq fayl deskriptori

sudo ls -l /proc/$(pgrep -x nginx | head -1)/fd

lrwx------ 1 www-data www-data 64 Jul 29 09:12 0 -> /dev/null
lrwx------ 1 www-data www-data 64 Jul 29 09:12 3 -> socket:[48212]
lrwx------ 1 www-data www-data 64 Jul 29 09:12 4 -> /var/log/nginx/access.log

lsof -p <pid> aynan shuni o'qib, siz uchun formatlaydi: jarayon hozir ushlab turgan har bir ochiq fayl, socket va pipe uning fd katalogi ostida symlink sifatida turadi. "O'chirilgan faylni qaysi jarayon hali ham ochiq ushlab turibdi va shu sababli uning disk joyi bo'shamayapti" degan savolga aniq javob topishning yo'li ham shu. O'chirilgan, lekin hali ochiq turgan fayl bu yerda manzil yo'li oxiriga (deleted) qo'shilgan holda ko'rinadi.

sudo ls -l /proc/*/fd 2>/dev/null | grep '(deleted)'

limits: jarayonga amal qilayotgan resurs cheklovlari

cat /proc/$$/limits | head -5

Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max open files             1024                 4096                files

Bu ulimit, PAM’ning limits.conf fayli yoki systemd unit’idagi LimitNOFILE= va shunga o'xshash direktivalar orqali sozlangan, jarayon aslida ishlayotgan cheklovlarning ishonchli, jonli ko'rinishi. Konfiguratsiya o'zgarishi faqat undan keyin ishga tushgan yangi jarayonlarga emas, allaqachon ishlab turgan muayyan jarayonga ham haqiqatan ta’sir qilganmi-yo'qmi degan bahsni shu faylni to'g'ridan-to'g'ri o'qib hal qilish mumkin.

Tizim bo'yicha umumiy fayllar: birorta jarayonga bog'lanmagan

/proc biror muayyan jarayondan mustaqil ravishda butun mashina holatini ham ko'rsatadi.

cat /proc/loadavg

4.15 2.03 0.98 2/187 22884

uptime va top sarlavhasi Jarayonlarni kuzatish maqolasida ko'rilgan load average qiymatlarini aynan shu manbadan o'qiydi: tanish uchta raqam, keyin "hozir bajarilishga tayyor / jami jarayonlar" va eng oxirgi yaratilgan PID.

cat /proc/meminfo | head -6

MemTotal:       16310924 kB
MemFree:          421356 kB
MemAvailable:    4198212 kB
Buffers:          198420 kB
Cached:          5488216 kB
SwapTotal:        2097148 kB

Bu yerdagi MemAvailable — free -h o'zining available ustunini aynan undan hosil qiladigan qiymat. Uni to'g'ridan-to'g'ri o'qish free xulosasiga ko'r-ko'rona ishonmasdan, uni tasdiqlash imkonini beradi. Bu odam o'qishi uchun formatlangan jadval emas, xom kilobayt qiymati kerak bo'lgan monitoring tekshiruvini skriptda yozganda foydali.

cat /proc/cpuinfo | grep -c ^processor

/proc/cpuinfo dagi processor yozuvlarini sanash nproc ko'rsatadigan o'sha sonni beradi, faqat nproc ning o'zi o'qiydigan manbadan to'g'ridan-to'g'ri olinadi.

Kernelni jonli sozlash: /proc/sys

/proc ning /proc/sys ostidagi qismi yozish uchun ochiq va kernel xatti-harakatini darhol o'zgartiradi — qayta yuklashsiz, xizmatni qayta ishga tushirmasdan:

cat /proc/sys/vm/swappiness

60

vm.swappiness (uni /proc/sys/vm/swappiness sifatida ham, aynan shu qiymat uchun afzalroq va xavfsizroq interfeys bo'lgan sysctl buyrug'i orqali ham o'qish mumkin) kernel page cache’ni qaytarib olishni anonim xotirani swap’ga chiqarishdan qanchalik ustun qo'yishini boshqaradi. Bu qiymat keyingi tizimni sozlash materiallarida chuqurroq ko'rib chiqiladi; bu yerda u aynan shu fayl tizimi orqali taqdim etiladigan jonli, yozish mumkin bo'lgan kernel parametriga misol sifatida keltirilgan.

sudo sysctl vm.swappiness
sudo sysctl -w vm.swappiness=10

Real vaziyat: o'chirilgan faylni ochiq ushlab turgan jarayonni topish

Muammo. df -h fayl tizimi 98% to'lganini ko'rsatyapti, lekin ko'rinadigan kataloglar daraxti bo'yicha du -sh bu joyning faqat bir qismini hisobga oladi va oddiy ko'zdan kechirish bilan ko'zga tashlanadigan katta fayl topilmayapti.

Avval taxmin qilmasdan farqni tasdiqlang:

df -h /var
du -sh /var/* 2>/dev/null | sort -rh | head

Agar du dan chiqqan yig'indi df band deb ko'rsatgan hajmdan ancha kam bo'lsa, yetishmayotgan joyni katta ehtimol bilan o'chirilgan, lekin hali ochiq turgan fayl ushlab turibdi.

Aynan shu andozani to'g'ridan-to'g'ri /proc dan qidiring:

sudo find /proc/*/fd -maxdepth 1 -lname '*(deleted)*' 2>/dev/null -exec ls -l {} \;

lrwx------ 1 www-data www-data 64 Jul 29 09:12 /proc/2214/fd/7 -> /var/log/app/debug.log (deleted)

Bu aslida qaysi jarayonga tegishli ekanini tasdiqlang:

ps -o pid,ppid,user,cmd -p 2214

Xulosa. debug.log fayli o'chirilgan (ehtimol to'g'ri log rotation o'rniga oddiy rm bilan), lekin 2214 jarayoni uni hali ham ochiq ushlab turibdi va ehtimol unga yozishda davom etyapti. Shuning uchun uning disk bloklari band bo'lib qolmoqda va hech qanday katalog ro'yxatida ko'rinmaydi. To'g'ri yechim — fayl tizimining hech bir joyida nomi qolmagan faylni qidirishda davom etish emas, egasi bo'lgan jarayonga log faylini qayta ochish uchun signal berish (ko'p xizmatlar buni SIGHUP da yoki maxsus reload buyrug'i orqali qiladi). Agar jarayon log'ini toza qayta ocha olmasa, nazorat ostida qayta ishga tushirish fayl deskriptorini va u bilan birga disk joyini bo'shatadi. Har ikki holatda ham kelajak uchun asl yechim — faol log fayllarini qo'lda o'chirish o'rniga to'g'ri log rotation (logrotate, keyingi modulda ko'rib chiqiladi).

Keng tarqalgan xatolar

Bir martalik sinov uchun /etc/sysctl.conf ni to'g'ridan-to'g'ri tahrirlash

Distributiv yoki paket yangilanishi bu faylni sezdirmasdan qayta yozib yuborishi mumkin. Vaqtinchalik, darhol sinov uchun sysctl -w dan foydalaning, /etc/sysctl.d/ ostidagi alohida faylni esa faqat o'zgarish saqlanib qolishi kerakligiga ishonch hosil qilgandan keyin yarating.

O'chirilgan faylning joyi darhol bo'shaydi deb o'ylash

Katalogdagi yozuv darhol yo'qoladi; ostidagi disk bloklari esa faylni ochib turgan har bir jarayon uni yopmaguncha band bo'lib qoladi. Mas’ul jarayonni topishning to'g'ridan-to'g'ri yo'li — ko'rinadigan daraxtda du ni qayta-qayta ishga tushirish emas, /proc/*/fd ni ko'zdan kechirish.

Skriptda /proc ni o'qish o'rniga ps yoki top chiqishini tahlil qilish

ps va top ning odam o'qishi uchun formatlangan ustunlari distributivlar va versiyalar o'rtasida sezilmas darajada o'zgarishi mumkin. Muayyan, barqaror sonli maydon (VmRSS, load average, ochiq fayl deskriptorlari soni) kerak bo'lgan skript ko'pincha mos /proc faylini proc(5) da hujjatlashtirilgan aniq formatda to'g'ridan-to'g'ri o'qisa, ishonchliroq bo'ladi.

Har bir /proc/sys qiymatini o'zgartirish xavfsiz deb hisoblash

Ko'p parametrlarni o'zgartirib, keyin qaytarish xavfsiz; lekin oz sonlisi noto'g'ri o'rnatilsa, tizimni darhol beqaror qilishi mumkin. Muayyan parametrga yozishdan oldin, ayniqsa /proc/sys/kernel/ yoki /proc/sys/vm/ ostida avval ishlatmagan biror narsa bo'lsa, doim kernel hujjatlarini tekshiring.

Jarayon tugashi bilan /proc/[pid] yo'qolishini unutish

/proc/<pid>/status ni siklda o'qiydigan skript tekshiruvlar orasida jarayon tugab qolsa, katalog o'qish o'rtasida yo'qolishini hisobga olishi kerak. Yo'q katalogni cheksiz qayta urinadigan xato holati sifatida emas, "jarayon endi mavjud emas" deb qabul qiling.

Mashqlar

1. Joriy shell’ingiz PID ini $$ bilan toping, so'ng /proc/$$/status ni o'qib, VmRSS qiymatini aniqlang. Uni o'sha jarayon uchun ps -o rss -p $$ ko'rsatadigan qiymat bilan solishtiring va ular mos kelishini tasdiqlang.
2. Fon jarayonini ishga tushiring va uning ichida faylni oching (masalan, o'zingiz yaratgan faylga nisbatan tail -f). tail -f hali ishlab turganida o'sha faylni rm bilan o'chiring va ls faylni nomi bilan endi ko'rsatmasa ham, uning ma’lumotlari hali ochiq deskriptor orqali mavjudligini /proc/<pid>/fd yordamida isbotlang.
3. /proc/loadavg ni to'g'ridan-to'g'ri o'qing va uning dastlabki uchta maydonini xuddi shu tizimda taxminan o'sha paytda uptime ko'rsatgan load average bilan solishtiring.
4. Hech narsani o'zgartirmasdan, /proc/sys/vm/overcommit_memory nimani boshqarishini (sysctl -a yoki kernel hujjatlari orqali) aniqlang va uni noto'g'ri o'rnatish nega vm.swappiness ni o'zgartirishdan xavfliroq ekanini o'z so'zlaringiz bilan tushuntiring.

Mashqni bajardim deyish uchun: 2-mashqdagi isbot o'chirilgandan keyin ham fayl mazmuni /proc/<pid>/fd/<n> orqali o'qilishini ko'rsatishi kerak — jarayon ishlashda davom etganini kuzatishning o'zi yetarli dalil emas.

Bu modul sizni qayerga olib keldi

Bu modul davomida Dasturlar va jarayonlar jarayon aslida nima ekanini va kernel uni qanday yaratishini tushuntirdi; Jarayonlarni kuzatish shu holatni top va htop bilan uzluksiz kuzatishni ko'rsatdi; Jarayon xotirasi xotira sarfini to'g'ri o'qishni o'rgatdi; Jarayon ustuvorligi CPU vaqti qanday taqsimlanishiga ta’sir qilishni ko'rib chiqdi; Signallar va jarayonlarni boshqarish ishlab turgan jarayonni tugatish, pauza qilish va u bilan muloqot qilishni ko'rsatdi; Foreground va background job’lar esa job qayerda ishlashini va u uzilishdan omon qolish-qolmasligini boshqaradigan shell’ning o'z qatlamini tushuntirdi. Bu maqola esa o'sha vositalarning har biri aslida kernel taqdim etadigan bitta ochiq fayl tizimidan o'qishini yoki unga yozishini ko'rsatdi. Demak, bu modulda ko'rilgan hech narsa sizda to'g'ridan-to'g'ri kirish huquqi bo'lmagan maxsus imtiyoz ortida yashirilmagan.

Keyingi modul jarayonlarning o'zidan dasturiy ta’minot tizimga birinchi navbatda qanday tushishiga o'tadi: paketlarni boshqarish, bog'liqliklarni hal qilish va o'rnatilgan dasturlarni xavfsiz yangilab borish.

Manbalar

• Linux man-pages: proc(5): https://man7.org/linux/man-pages/man5/proc.5.html
• Linux kernel hujjatlari: filesystems/proc.rst: https://www.kernel.org/doc/html/latest/filesystems/proc.html
• Linux man-pages: sysctl(8), sysctl.conf(5): https://man7.org/linux/man-pages/man8/sysctl.8.html
• Linux kernel hujjatlari: vm.* uchun sysctl hujjatlari: https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html
• Linux man-pages: lsof(8): https://man7.org/linux/man-pages/man8/lsof.8.html
• Ubuntu Server hujjatlari: kernel hujjatlari va sysctl: https://ubuntu.com/server/docs