Názory k článku Co před námi tají /proc (1)
-
Článek je starý, nové názory již nelze přidávat.
-
Prcek (neregistrovaný)
Tema se objevilo, alespon pro mne, v pravou chvili. Vcera jsem badal nad tim, co je v souboru /proc/loadavg - statistika o poctu procesu a uptime - alespon tak jsem to pochopil podle manualovych stranek. Co jsem ale nezjistil, kde by se dalo splasit cislo kolik % casu stravi system diskovymi operacemi. Nemohlo by to byt v nekterem z pristich pokracovani ?
Rozhodne dik, tohle se mi zrovna hodi. -
Petr Baudis (neregistrovaný)
pasky@machine:~$ cat /proc/stat | head -1
cpu 131726 300 38556 8711687
kde tento radek je generovan prikazem
len = sprintf(page, "cpu %u %u %u %lu\n", user, nice, system, jif * smp_num_cpus - (user + nice + system));
coz znamena ze tyto cisla znamenaji kolik casu stravil procesor chroustanim uzivatelskych programu, zanajsovanych programu, a systemoveho kodu, a nakonec kolik stravil lelkovanim - takze jednoduchy vypocet celkove zateze procesoru jest load[%]=($1+$2+$3)/($4-$1-$2-$3)*100 -
Michal Kara (neregistrovaný)
Dovolil bych si trochu upresneni. Onu "diskusi v konferenci linux@linux.cz" jsem rozpoutal ja svym dotazem, jestli nekdo nema podrobny popis procfs a jestli kdyz ho napisu, bude o nej zajem. Zajem byl, tak jsem zacal psat. Uz to mam skoro hotove, chybi mi jeden adresar a dnes vidim na rootu tento clanek. Kdyby se autor alespon ozval, ze dela neco podobneho, mohli jsme spojit sily...
K dotazu ohledne "casu straveneho diskovymi operacemi". Pokud vim, nic takoveho z /procu nezjistite a nezjistite ani pocet prenesenych bloku per proces (jen globalne v systemu). Pokud proces bezi na systemu sam a ceka jen na disk, lze to zhruba odvodit od vytizeni systemu. Ale prozo, uz jsem videl system, ktery byl zatizen na 60% a pritom podle vypisu topu jeden proces bral 3%, dalsi 1% a zbyle skoro nic... -
Tomáš Krause (neregistrovaný)
Pokud se kdokoliv chystate napsat clanek o cemkoliv tematicky se hodicim pro ROOT.cz a chcete ho u nas i zverejnit (samozrejme za honorar), napiste nam a podobnym problemum muzeme predejit.
Ale samozrejme neni problem uverejnit dva clanky od ruznych autoru na jedno tema, pokud se nebudou vylozene prekryvat. -
petr (neregistrovaný)
Toz skoro vsecko jasne, akorad nerozumim, kde autor vzal syntax pro ps:
$ps -e rovno 300
Je to OK? A ma to nejakou souvislost s CZ Linuxem??
u me se proces s danym pid vypise takto:
$ps -p 300 (RedHat Linux 6.1, US)
Pokud jsou ty linuxy vzajemne nekompatibilni, pak to neni dobre... -
Tuttle (neregistrovaný)
Velmi hezky clanek, skoda, ze Lemming psal podobny, ale mohl se prece ozvat i on. Doufam, ze ho nebude publikovat pouze v Linuxove konferenci. >;-)
Vsiml jsem si v textu poznamky o TracerPid, juknul na Google a nasel par patchu, v jadre byla chyba pri vypisu tohoto cisla. Mam jadro 2.4.3 (a nepripadam si jako sebevrah>;-) a ta chyba uz vypada opravene.
Pak mne napadlo to vyzkouset, treba intuice nezklame. Spustil jsem dalsi bash a z vedlejsiho okna ho zacal trasovat pomoci attachnuti gdb (gdb /bin/bash <jeho-pid>). Nu a jak tracing zacal, objevil se pid gdb-cka jako TracerPid toho bashe v /proc/<jeho-pid>/status.
Takze bych se odvazil tvrdit, ze TracerPid pro proces1 udava pid procesu2, ktery proces1 trasuje (nula znamena, ze proces neni jinym trasovan).
Trasovani se pouziva pro ladeni jiz existujicich programu. Na unixu se muzete pripojit k jiz bezicimu procesu, zastavovat ho, zkoumat jeho pametovy prostor a pokud mate k dispozici i jeho zdrojaky, muzete z toho byt natolik moudri, ze najdete chybu, protoze mate moznost sledovat zivot programu in-natura. Dale odkazuji na info gdb. -
Tomas Kasparek (neregistrovaný)
No dostal jsem se k netu, tak jen co si myslim na polozene otazky:
- s lemmingem jsme se uz domluvili, clanky na rootu dopisu ja
- pri syst.programovani se radeji pouzivaji sluzby jadra, jsou standartizovanejsi, proc je pomerne nekonzistentni mezi ruznymi Unix-* systemy. Jinak vyuziti proc primo neni nic moc dobry napad, lepsi (pro prenositelnost) jsou knihovny typu libproc
- sebevrah nejsem, jadro 2.4.5 je vsak v soucasnosti posledni stabilni (v dobe psani clanku) a jsou lide, kteri poslednim jadrum moc neveri, protoze je jeste nikdo delsi dobu netestoval. Osobne bych pri nasazeni na nejaky server take radsi zvazil neco "lehce" starsiho. Ale to by byla dlouha diskuze.
- TracerPid - podle logiky to odpovida ale v jadre 2.4.5 ktere mam k dispozici se tam proste natvrdo dosadila '0'. Pokud existuje patch, diky za nej
Pokud mate nejake napady, pripominky ohledne obsahu a hlavne zpracovavanych adresaru, neco vam chybi (SCSI, ???) dejte vedet (na e-mil) -
Petr Baudis (neregistrovaný)
Podivame-li se (v jadre 2.4.5, kdo ma stalee stahovat nove jadro a hlavne pak rebootovat pocitac ;) do /usr/src/linux/fs/proc/base.c, na radce 315 nalezneme
funkci mem_read(), ktera obsluhuje prave cteni/zapis do tohoto souboru. A protoze jsme si po stracnuti onoho cat /proc/%d/mem zjistili, ze syscall vraci -ESRCH, podivame se po nem - a nalezneme ho hned na zacatku, jako:
if (!MAY_PTRACE(task))
return -ESRCH;
kde MAY_PTRACE je definovano jen kousek vyse, jako:
#define MAY_PTRACE(p) \
(p==current||(p->p_pptr==current&&(p->ptrace & PT_PTRACED)&&p->state==TASK_STOPPED))
z toho vyplyva, ze z bezpecnostnich duvodu muzeme pracovat s timto souborem (totez je u mem_write) pouze, pokud ulohu prave ptrace()ujeme, a pokud je zrovna zastavena. U prave beziciho bashe tedy mame smulu ;-) -
pio (neregistrovaný)zdravim mam jeden dotaz ktery jen okrajove souvisi s temou.
a to seznam pouzitych soubor procesu
tedy to co je nalinkovane v /proc/cislo_procesu/fd/
a ted k dotazu
jedna se o procesi httpd
neni mi zcela jasne proc tomu tak je
kdyz dam
#ls -la /proc/12345 | grep cwd
dostanu
cwd -> /home/www/domenaX
z neznamych duvodu jsou v /proc/cislo_procesu nalinkovany vsechny access_logy
tedy
#ls -la /proc/12345/fd
100 -> /cesta_k_logu/access_log.domena1
101 -> /cesta_k_logu/access_log.domena2
123 -> /cesta_k_logu/access_log.domena3
...
je tam jeste nejaky bordel kolem ale bohuzel nejsem schopnej dohledat
ktery soubor skutecne bezi.
dik za kazde info.
