Ruby + sysstat #2

Előzmények itt.

Most eltávolítottam az uptime és pidstat parancs (sysstat csomag) függőséget is a kódból, így ha nincs acpi és pydf sem, a fontosabb infót akkor is meg tudja jeleníteni. E két utóbbi csak opcionális függőség. Kb. 20 %-al gyorsabb is lett így a kód (0.1 sec alatt fut).

Tesztelve Ruby 1.8.5 - 1.9.3 verziók között. Forráskód itt, letöltés itt.

Ha lenne valakinek kedve, le tudnátok tesztelni friss (>3.0.x) kernel alatt? Illetve régi 2.6.18-as (pl. Debian Etch vagy CentOS 5 talán?) kernellel? Ugye a /proc-ban turkálok, és ezért érdekes a kernel verzió.

Szerk.: Ubuntu11.10 (kernel 3.0.0) alatt jó. SL 5.6 alatt (kernel 2.6.18, Ruby 1.8.5) is ok.

( tompos v | 2012. 01. 28., szo – 17:50 )

Hardy, uptodate Precise, Lucid LXC guest Oneiric hoston OK

Helyesbitve guest-en termeszetesen annyira csak annyira OK, amennyire a system tool-ok is mutatjak, nem a guest ertekeit mutatja.
Ha azokhoz irnal procps replacement-eket, annak tobb ertelme lenne:)

BTW, mi a a celod ezekkel a scriptekkel? Just for fun?

tompos

"Helyesbitve guest-en termeszetesen annyira csak annyira OK, amennyire a system tool-ok is mutatjak, nem a guest ertekeit mutatja. Ha azokhoz irnal procps replacement-eket, annak tobb ertelme lenne.."

Ezt kifejtenéd bővebben? Keresgetek a témában, de nem tiszta.

A type2-es hypervisor virt miatt van ez? Ha igen, akkor azt mondod hogy nem valós értékeket kapok a guest rendszeren a folyamatok erőforrás használatát illetően? A kernel jelenti ezt le rosszul?

A LXC kontener eseten a /proc-ban a host ertekei talalhatok meg.
A guest a cgroup fs-en keresztul szabalyozhato es monitorozhato.

Tehat nem rosszul mutatja, csak mashol. Igy a hagyomanyos tool-ok (procps) hasznalhatatlanok.

http://www.kernel.org/doc/Documentation/cgroups/
Gondolom leginkabb a memory.txt erdekes szamodra.

tompos

( Kambus | 2012. 01. 28., szo – 17:07 )

CentOS 6.2 (2.6.32-220.4.1.el6.x86_64) -- OK
Fedora 16 (3.2.2-1.fc16.x86_64) -- OK

Ami szúrta a szemem: File.exists?(file) helyett érdemes File.file?-t használnod, mivel könyvtarakon is ott szokott lenni az x bit. Itt nem számít ugyan, de ha platformfüggetlen which-et akarsz akkor File::PATH_SEPARATOR-ra nézz rá, ill. PATHEXT-en nemárt végigmenni.

Igazad van, a File.file? kell a which rutinomba (javítva). Köszi.

PATH_ var-okat megnézem, de még nem találkoztam vele. Gondolom a létezésüket kell vizsgálni, és ha már van értékük, akkor ez alapján végezni a string műveleteket?

Szerk.: találtam is rá példát, bár a kódom Linux only.

Igen, ugye POSIX rendszereken ':' a path elválasztó karakter, de winen már ';'. PATHEXT azért kell, mert könnyen belehet nézni olyanokat, hogy pl meghívod unrar-t és működik rendesen. Viszont which ennek ellenére mégis azt fogja mondani, hogy nincs ilyen file, mert az valójában unrar.exe.