/etc/inittab

[dexter]

jestem pewien na 10000%

przy poleceniu faxaddmodem pierwsze pytanie dotyczy portu - jak podaje ttyS0 to modem jest rozpoznawany, Hylafax negocjuje sobie predkosci transmisji itp.

Po ustawieniu wszystkich opcji serwera faxu wlaczam faxgetty przez

telinit q

w logach pojawia mi sie info o otwarciu portu /dev/ttyS0 (ale nie ma zadnego info o bledach)

potem robie restart uslugi Hylafax

/etc/init.d/hylafax restart

do logow trafia info o wystartowaniu uslugi hylafax, nastepnie lacze sie do serwera klientem whfc. W oknie statusu klienta dostaje komunikat o oczekiwaniu na gotowosc modemu, a w logach pojawia sie wstawiony w poprzednim poscie wpis

edit: dodatkowo o poprawnosci wyboru porty swiadczy fakt, ze jesli odpalam program minicom to jesli wczesniej nie zamkne faxgetty dostaje blad

Device /dev/ttyS0 lock failed: Operation not permitted.

A jak zamkne faxgetty to program sie uruchamia i moge bez problemu zrobic ata <numer> i za moment dzwoni moja komorka

[TQM]

Ehhh w takim razie wybacz ale nie widzac tego na wlasne oczy nie wiele moge poradzic

[dexter]

i tak wielkie dzieki za okazaną pomoc - będę próbować jeszcze - może się uda

[I_v0]

Moment,

Co DOKLADNIE odpalasz z inita? Skrypt ktory inicjalizuje pewne zmienne srodowiskowe czy bezposrednio binarke programu?

Bo z logow ktore przytoczyles wynika ze program startuje wiecej niz raz (tak mi sie przynajmniej zdaje).

Dziac sie tak moze gdyz (for example) init startuje to co mu kazales co byc moze jest skryptem i tenze skrypt startuje wlasciwy program po czym wychodzi. Z perspektywy init -a program ktory jest na respawn zakonczyl prace wiec trzeba go przywrocic.

Tu trzeba rozumiec zasade dzialania procesow w systemach UNIXowych.

Ja ta historie widze tak:

Init tworzy dziecko [ fork() ], juz mamy nowy proces (i nowy PID). Init zapisuje sobie PID dziecka i czeka az dziecko zakonczy prace.
Dziecko w tym przypadku jest skryptem bash -a, inicjalizuje wszystkie zadane zmienne srodowiskowe (i generalnie wykonuje jakas prace - jak to skrypt basha) po czym na koncu odpala binarke zajmujaca sie portem ttyS0.

Zwrocmy uwage na definicje slowa "odpala". Ten skrot myslowy oznacza wytworzenie nastepnego potomka (nastepny PID). Wiec mamy juz w tym momencie trzy PIDy.

init - 1
skrypt - 2
binarka - 3

<dygresja>

W rozumieniu specyfikacji języka C99 mozemy znalzezc zapis ze nowy proces na wejscie do funkcji main() dostaje cztery rzeczy:

1. Ilość parametrów podanych w linii komend
2. Parametry podane w linii komend
3. Ilosć zmiennych
4. Zmienne

Wg specyfikacji basha każdy nowy potomek tej powloki pobiera zmienne srodowiskowe od swojego ojca - a wiec najpierw idzie wywolanie fork() a nastepnie w utworzonym lustrze wywolywane jest execve() nie tylko z parametrami jakie skrypt podaje do binarki w "linii komend". Ale takze ze wszystkimi zmiennymi srodowiskowymi tak jak zostaly one ustawione w procesie skryptu.

</dygresja>

Binarka raz odpalona z poprawnymi zmiennymi srodowiskowymi i parametrami linii komend binduje sie do ttyS0 i dziala poprawnie.

Jednakze zauwaz ze skrypt po odpaleniu binarki konczy prace. Wiec w oczach initu program wpisany w inittabie skonczyl prace a pozniewaz jest on ustawiony jako respawn to restartuje skrypt i petla trwa w kolko za kazdym razem odpalajac nowa instancje binarki.

Z tym ze tylko pierwsza instancja przezyje poniewaz wszystkie nastepne zobacza ze port jest zajety i sie odjebia.

Rozwiazaniem problemu moze byc uzycie w skrypcie funkcji exec ktora zapobiegnie tworzeniu nowego procesu podczas uruchamiania binarki z wnetrza skryptu. W przypadku exec binarka "zastapi" proces skryptu. Wiec z punktu widzenia initu jego dziecko nadal dziala i ma sie dobrze wiec nie bedzie ruszal.

Acz nie jestem pewien czy to jest ten problem. Sprawdz co DOKLADNIE sie dzieje.

Pozdrawiam,
I_v0

[dexter]

Świetny post - dowiedziałem się paru ciekawych rzeczy

Niestety, linijka w inittab to

t0:2345:respawn:/usr/sbin/faxgetty ttyS0

W komputerze jest zainstalowany drugi modem (wewnętrzny) i występuje jako ttyS1. Z wewnętrznym nie ma żadnych problemów, powyższe polecenie z parametrem ttyS1 działa OK.

Polecenie w inittab odpala binarke jaka jest kopiowana przy instalacji hylafax

[I_v0]

Hmmm, nie wiem, wlasciwie to ja bym to próbował chwycić strace -em i zobaczyć dlaczego nie działa. Tak to brak pomysłów, robię support na codzień ale troszke innych systemów (btw. też faxy przesyłamy, ale to CISCO i protokół T.37).

Dobrze że chociaż post Ci się spodobał, sorki że pomogłem za wiele.

Ah, coś mi jeszcze wpadło do głowy, może spóbuj z crontaba odpalać ten hylafax? Też to można jakoś było robić, z eggdropami ludzie swego czasu to robili, ale tutaj to nie jestem w stanie z głowy podać jakiejś konfiguracji.

<EDIT>
Żeby być bardziej specyficznym to można tak ustawić crontaba żeby przy starcie systemu się odpalał dany program - teraz tak mi się jarzy że można dać tam odpalanie skryptu co minutę. Skrypt sprawdza czy program stoi (ps -auxw| grep hylafax) i jeśli tak to nic nie robi, a jeżeli program jednak nie działa to go odpala. Ale była jakaś bardziej seksowna droga żeby to zrobić, tylko nie pamiętam jaka teraz - dawno to było.
</EDIT>

Pozdrawiam,
I_v0

[dexter]

No i skończył się dzień dziecka - zdaje się, że tego przypadku już nie odkryję
Zmieniłem pracę - w związku z czym straciłem dostęp do maszyny, na której to było postawione.
Przed odejściem tylko przerzuciłem działanie HylaFax na modem wewnętrznyi finito.
Wielkie dzięki za pomoc zaangażowanym

@I_vo
sprawdziłem tylko, że proces faxgetty inicjowany z inittab to elf-ka, więc nie powinno być problemów z pid-ami o jakich pisałeś.

Pomimo nierozwiązania tej kwestii, z wątku płyną również pozytywne aspekty
1.zmieniłem prace
2.poznałem exec
3.usłyszałem o strace
4.ZMIENIŁEM PRACE

[TQM]

No to gratulacje z powodu zmiany pracy - kazda zmiana jest na lepsze... przynajmniej tak dlugo jak system jeszcze dziala