Witam Tomasz,

Saturday, June 11, 2005, 12:10:36 AM, you wrote:

On Sat, 11 Jun 2005 00:01:04 +0200, JacekK wrote

...

Jesli jeden ze z modolow daemona jest przetwarzany ponad 60sec ( co tyle chyba lmsd sprawdza czy nie ma przeladowania ) to lmsd zaczyna odpalac nastepne modoly !! I zaczyna sie jazda !!! Prosze sobie wyobrazic: odpala sie modol firewalla ( generowanie skryptu i uruchomienie trwa ponad 60sec ) i po 1 min odpala sie kolejny modol np TC ( generowanie kolejek htb dla klientow ). W pewnym momencie obydwa skrypty przetwarzaja sie rownolegle !!!! ( TOTALNA SIECZAK NA SERWIE, tylko reboot moze pomoc ) LMSD dziala dobrze pod warunkiem ze modol ktory przetwarza, skonczy swoja prace przes 60sec !!, bo jak nie to uruchomi to samo w kolejnym procesie !!!!!

LMSD powinien tworzyć jakieś pliki blokad na dysku i przy każdym uruchomieniu testować czy nie istnieją lub powinien sprawdzać czy nie ma procesu już działającego o nazwie lmsd. Ja u siebie tak robię używają serii skryptów perlowych żeby nie doszło do zagnieżdżonego uruchamiania tych skryptów...

Problem juz rozwiazalem, wystarczy troszke kod lmsd.c zmodyfikowac. lmsd uzywa tylko 2-och stanow 0="brak przeladowania", 1="żadanie przeladowania".

Wprowadzilem 3-stan 2="przeladowanie w toku", i juz lmsd, nie wywoluje ponownie tego samego żadania przeladowania po 60sec.

Oto zmiany w kodzie lmsd.c Linia 170: //res = db_query(g->conn, "SELECT reload from daemonhosts WHERE name = '?' AND reload !=0",dbhost); zmiana na: res = db_query(g->conn, "SELECT reload from daemonhosts WHERE name = '?' AND reload =1",dbhost);

I dopisanie zmiany statusu w bazie, jesli rozpoczelo sie przeladowanie: Linia 340 ( przed uruchomieniem modolow ), zmiana statusu reloadu na 2 db_pexec(g->conn, "UPDATE daemonhosts SET reload = 2 WHERE name = '?'", dhost);

Przy okazji, mozna by ten stan "2" (reload=2) wykorzystac w skryptach LMS-a, by informowac poprzez UI ktore instancje w danej chwili sie przeladowywuja .