Názory k článku
Co před námi tají /proc (1)

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.

Zdravim,
pokial viem, informacie tohoto typu (ktore zobrazuje FreeBSD a to uz nehovorim o solarise) v linuxe nie su, pretoze ich jadro nepocita. Ak by niekto patchol jadro tak aby toto ratalo, mohol by rovno urobit aj nejaky specialny subor do /proc :)

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

Děkuji za tento članek, zase o trošku více budu vědet,
jak to vlastně funguje. Jenom bych se přimlouval o trosku více omačky při vysvětlování. Nejsem počitačově vzdělán a jako samouk všemu nerozumím. Jinak je moc dobrý, že to je vysvětlovano na konkrétním příkladu.

Zdravi Jura

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...

Myslím, že vůbec nebude vadit, když zveřejníte svou práci na totéž téma. Určitě jsou i věci, ve kterých se nepřekrýváte.

Jasne, zverejnete to. Vic hlav vic vi.

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.

Diky za tenhle clanek a dalsi, ktere budou, doufam, nasledovat. Pro toho, kdo neumi cist primo zdrojaky jadra je to vyborne.

Dik za clanek, prihazuji spousty Q :o]

Díky za Qčka ty mamlasi, budem ve vatě. A vy ostatní, přihazujte, hovada!

Hmmmmmm, velice odusevnele...

Bohuzel (bohudik?) je prispivani do diskuze tak jednoduche, ze ho zvladne i anonym s IQ okolo teploty vzduchu.
Doufam, ze netreba vysvetlovat, ze autor prispevku nema nic spolecneho s redakci ROOT.cz.

Upozornuji, ze teplota vzudu muze byt i pres 50 a neni to nic zvlastniho. Coz bych u autora kritizovaneho prispevku nerekl.

A jsou to stupne Celsia nebo Fahrenheita? ( nedej Boze, aby to byly Kelviny :-))

PS: At zije flame.

Toto je velmi tezke. Sve systemy mam opatchovane
takze se mi zobrazuje v /proc/loadavg i time pro D
status. Normalne je v loadavg EWMA poctu R procesu.
Proces je v D stavu pokud ceka na diskovou operaci
ci jine neprerusitelne cekani. Ale naprosta vetsina
je disk.

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...

nejen bashovou syntaxi ziv je clovek, je dobre chapat i slozitejsi vetne celky v jazyce rodnem, zvlaste je-li prikaz "ps -e", vypisujici udaje o vsech procesech, zretelne oddelen od ceskeho "rovno" pomoci kurzivy. :))

Taky jsem naletel:-) Ona totiz v linksu ta kurziva nebyla videt...

mam blbej dotaz........ proč bys měl být s jádrem 2.4.5 sebevrah??? je snad stabilně nestabilní či co? :o)

Mam jeste hloupejsi dotaz. Kdesi v literature jsem se docet, ze liche cislo na konci znamena verzi nestabilni. Jak to tedy je? Diky.

s tou lichosti je to na druhe pozici. 2.4.x je stabilni ale treba 2.3.x je nestabilni

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.

Pouziva se pri programovani sys. aplikaci
pristup k /proc; nebo vice nejake sluzby jadra.
(POZOR! Me vedomosti o sys. programovani v Linuxu
jsou temer nulove)

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)

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 ;-)

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.