Dotaz: Jak dlouho je proces v read()?

[xvasek]

Ahojte,

mám před sebou problém, kdy potřebuju zabít instance serveru (procesy), které dlouho nic nedělají. Server typicky volá read(), ve kterém je "zaseknutý" dokud nedostane data a jakmile je dostane, tak je zpracuje, něco udělá a pak zase visí v read(). Představoval bych si to tak, že např. každou hodinu poběží cronjob, který projde procesy serveru a ty, které jsou v read() už více než čtyři hodiny, tak zabije. Dá se nějak poznat, kdy (nejlíp v sekundách od začátku epochy) ten proces zavolal read(), ve kterém teď visí, popřípadě kolik sekund už tam visí doteď?

Předem díky.

Odpovědi

[psonek]

Pred read() nekam zapsat svuj PID a akt. cas, po dokonceni readu zase zapsat, ze uz se operace dokoncila.

V tom cronjobu pak precist PIDy a podle casu je pozabijet.

Jinak read() operace se da prerusit z jineho vlakna pres pthread_kill() a nebo je mozne pouzit async io. Externi zabijec je zajimavej, ale spis by se mel korektne ukoncit sam server podle me.

[xvasek]

Aha, to jsem mohl napsat do dotazu - server je closed-source. Vím o něm, že jej můžu bezpečně zabít přes kill -15. Ono je to v praxi tak, že chci implementovat automatické odpojování uživatelů při nečinnosti, protože nepřítomnost komunikace se rovná tomu, že uživatel s daným oknem nepracuje. Výrobce tuto funkci neplánuje, tak jsem chtěl vzít spravedlnost do vlastních rukou. Taky by mi to vyřešilo mé problémy s freetds, protože to se dostane do stejného stavu, pokud se restartuje MSSQL server. (Timeouty freetds mám nastavené, ale nepomáhá to.)

[lofcek]

Myslim, ze takto moze program napisat iba velmi neskuseny programator (po slovensky blb) a takyto program moze nainstalovat iba velmi neskuseny administrator (do slovenciny radsej neprekladam).

Nie .. prenositelny a jednoduchy sposob ako toto spoznat neexistuje. Zrejme by sa to cez velke hacky dalo zistit, ale myslim, ze ovela vhodnejsie je autora tohto programu kopat do zadnej casti tak dlho, kym to neopravi.

Tento sposob opravy ma mnohe vyhody - zlepsuje prenositelnost kodu, ma mensie hardvarove naroky a znamena aj jednoduchsiu administraciu systemu.

[stativ]

Určitě by to šlo přes profiler. To je ale blbost, protože ten běh nehorázně zpomalí.

Já bych na to šel cestou LD_PRELOAD. Vytvořil bych si knihovnu s fcí read(), která by někam uložila záznam o čase jejího zavolání. Po jejím dokončení by se zase záznam smazal.

[xvasek]

Zajímavý nápad, ale myslel jsem, že by to mohlo jít jednoduššeji z té hromady čísílek, která jsou v souborech v /proc/PID, každopádně toto vypadá taky schůdně.

[rADOn]

Jestli ten server pro kazde spojeni spawnuje novy pracovni podproces, stacilo by nastavit mu nejaky rozumny cas na zivot pres ulimit nebo proste signal na budik.

[xvasek]

Nene, takto to nejde. Je mi jedno, kolik si proces vezme zdrojů. Velký proces, který pořád sedí na CPU a pořád komunikuje, je "dobrý", naopak malý proces, který nic dlouhodobě nedělá, je "špatný" - bere totiž licenci ze serveru.

Jinak pokud by to pomohlo, tak to celé běží přes inetd / xinetd, ale tam jsem se díval a ten tuto funkci nepodporuje - otevře socket, přilepí vstupy / výstupy a dál se o to nestará.

Tak mě tak napadá, že by to tím pádem mohlo jít přes nějaké tee jednak k serveru a druhak do watchdogu, který by nečinnost vlastnoručně "trestal". (Ale původní idea "zjisti, jak dlouho už stojí ten read() a zabij to" mi přijde jednodušší, ale jestli nic takového nejde...)

[rADOn]

nápad: v cronjobu si někam poznačit cpu time spotřebovaný dotyčným PID. Pokud při příštím spuštení bude stejný, proces visí.

[michich]

Nebo třeba počet přepnutí kontextu, které proces zažil. Je to někde v /proc/PID/... Při zapnutém CONFIG_SCHEDSTATS je tam někde i časová značka, kdy šel proces spát.

[xvasek]

To si právě myslím taky. Původně jsem ten dotaz pokládal s tím, že někdo za 5 minut vysype z hlavy, kde ta značka je.

[lofcek]

Existuje aj dalsie riesenie .. a sice, ze inet daemon by spustil Vas program na monitorovanie aktivity. Tento program by nasledne spustil prislusnu ulohu a predposielal by jej vsetky vstupy a vystupy. A ked by ziadne citanie ani zapis neboli nejaky dostatocne dlhy cas, tak by ju cez kill poslal do prec.

Ale stale si myslim, ze opravit utilitku aby sa nazasekla pri open je v 99% pripadov jednoduchsie ako tahat kalibre ma monitoravanie aktivit procesu.

[lofcek]

Kazde volanie je prerusitelne (ak neobsahuje kernel chybu - uz som videl aj to). Signaly ako SIGINT, SIGHUP, SIGTERM sa daju ignorovat, ale SIGKILL (a este SIGSTOP - ale ten teraz nepotrebujeme) sa neda.

[frEon]

read() je syscall, tudiz proces, kterej je uprostred blokujiciho volani read() nezabijes protoze je v neprerusitelnem spanku. Doruceny signal se zpracuje az prave probihajici syscall skonci.

[michich]

Jak víš, že ten spánek bude nepřerušitelný? Pravděpodobně ten proces čte z nějaké roury nebo soketu, to bude přerušitelné.

[pht]

v dokumentaci od read je že vrací EINTR pokud je přerušen signálem, ergo dojde i k přepnutí kontextu a obsluze signálu.

[frEon]

nj, koukam. mas pravdu

[xvasek]

Přesně tak, když to přes kill zabiju, tak si to korektně ukončí session k aplikačnímu serveru - je to v dokumentaci toho serveru.

[Semo]

V jadre 2.6.36 pribudol do iptables filter testujuci dobu necinnosti spojenia. Ale ak po spojeni behaju keepalive pakety, tak to nepomoze. Ak ale tvrdis, ze server visi v read(), tak keepalive pakety asi nebehaju a dalo by sa to tymto mechanizmom rozpoznat.

Ak nemozes mat najnovsie jadro, tak by som sa priklonil by som sa ku jednoduchemu forwarderu medzi xinetd a samotnym serverom, ktory bude pocitat cas od posledneho prietoku dat. A ak expiruje, tak strihne spojenie, co by server mohol vyhodnotit ako odpojenie klienta.

Vyhol by som sa podstrceniu read() cez LD_PRELOAD, pretoze tym by si prepisal aj vsetky ostatne vyskyty read pouzite na inom mieste servera.

[darkenik]

otazka je este, ze na akom OS to bezi. v Solarise by sa to dalo robit nejak cez dtrace skripty. A pokial viem, tak linux ma na sledovanie tiez nejaku sadu *trace prikazov a nejaky sposob sledovacich bodov v kerneli.

[xvasek]

Linux, nejčastěji Debian 5, ale taky RHEL 4 a výš. Dávat tam nedistribuční jádro se mi moc nechce.