neukoncujici se proces

[Dan Lukes]

Jaroslav Votruba napsal/wrote, On 07/15/09 06:29:
> dneska rano se mi sprajcla MYSQL a ani bohovi nesla shodit.

> Stopping mysql.
> Waiting for PIDS: 928, 928, 928, 928, 928, 928, 928, 928, 928, 928, 928, 

Tak zaprve je treba zjistit, jestli se opravdu "sprajcla MySQL" nebo 
selhal detekcni mechanismus, ktery nespravne tvrdil, ze stale bezi ac uz 
nebezela. Jinymi slovy - zjistit, jestli stale bezi. Protoze odlisna 
odpoved na tuto otazku prinasi dva zcela odlisne smery dalsiho patrani.

Predpokladejme ale, ze se skutecne neukoncila MySQL. Pak je ale treba se 
zabyvat stavem MySQL - to jest - prihlasit se na konzili SQL serveru, 
podivat se jake zrovna resi dotazy. A pokud tohle zkoumani neprinese 
vysledek tak se spis obratit na nektere forum zabyvajici se MySQL...

Nezavisle na tom proc se MySQL "sprajclo" ale problem lze az na vyjimky 
vyresit prostredky OS - a tim myslim trochu jemejsi nez "restart".

'kill' (a mysql-server stop nepouziva nic jineho) posle procesu jen 
signal s vyznamem "uzivatel by byl rad, abyses laskave ukoncil". 
Signalu s timto vyznamem je nekolik a pokud server neni ochoten vyhovet 
jednomu je stale jeste mozne, ze zareaguje na jiny. No a v krajnim 
pripade lze zaslat signal SIGKILL (-9 nebo -KILL)  ktery ve skutecnosti 
signalem neni - to je skutecne pokyn pro OS aby proces odstranil zpameti 
(bez toho, ze to s nim bude nejak konzultovat).

Posledni moznost selze jen v pripade, ze "zadrhnuty" proces je zrovna 
obsluhovan jadrem - v takovem pripade se provede az obsluha skonci a 
dale v pripade, ze na dokonceni tohoto procesu ceka jiny proces a jeste 
neprevzal o ukonceni zpravu - ale v tomto pripade "zabijeny" proces uz 
nebezi, jen je formalne uveden v tabulce procesu (kvuli tomu 
cekajicimu). Pokud by v tomto stavu setrvaval dlouho pak je problem 
(take) s otcem.

Pri nepodminenem sestreleni je treba chapat, ze program byl skutecne 
ukoncen "nahle" - to znamena, ze cokoliv co delal nemusi byt v rozumnem 
konzistentnim stavu. Treba obsah databaze ...
						Dan