Re: mgetty и bforce

From

Andrey Slusar (2:467/126)

To

Igor Mitichev

Date

2005-08-23T23:21:18Z

Area

RU.UNIX.FTN

Tue, 23 Aug 2005 19:07:28 +0300, Igor Mitichev wrote to Elohin Igor':

 >>> Так вот как раз imho у mgetty и bforce lock'и разнесены по разным
 >>> каталогам. Где это прописывается тут говорили. Проверь этот вопрос.
 EI>> Если mgetty или точнее vgetty стоит в качестве автоответчика - о
 EI>> каком lock'е может идти речь ? Он просто слушает порт.

 IM>     Рассказываю. Mgetty запускается из файла /etc/inittab примерно
 IM> следующей командой: d2:2345:respawn:/sbin/mgetty -D /dev/ttyS1 (в твоем
 IM> случае, видимо, -D не будет).
 IM>     При этом, он действительно с одной стороны слушает модемный
 IM> порт. Разберем эту сторону. Когда из модема поступает "Ring", mgetty
 IM> отвечает в порт "ATA", после чего модем поднимает трубку и устанавливает
 IM> соединение. Какое это будет соединение -- пока не понятно. Но в
 IM> конце-концов со стороны модема что-то приходит. Вот это что-то и
 IM> анализируется mgetty. И на основании этого анализа mgetty запускает
 IM> дочернний процесс (будь то pppd, фидошный мейлер или любой другой
 IM> прикладной софт), а сама прекращает работу, выгружается из
 IM> памяти. Запушенный дочерний процесс делает свое дело, а по его
 IM> завершении так же прекращает работу. Модемный порт остается
 IM> "безхозным". Но! Но в упоминаемом выше файле /etc/inittab есть одна
 IM> замечательная способность: процесс, запущщеный в режиме respawn если и
 IM> прекратит свою работу, то будет по-новой перезапущен системой. Таким
 IM> образом, как только порт освобождается, система запускает новую копию
 IM> mgetty, которая и продолжает отслеживать состояние порта. Это с одной
 IM> стороны. Но есть и другая сторона: mgetty с этой другой стороны смотрит
 IM> в каталог /var/lock. И если обнаруживает там флаг занятости порта, так
 IM> же завершает свою работу. То есть при, например, исходящих звонках,
 IM> фидошный мейлер создает флаг занятости порта, mgetty, отследив этот
 IM> момент, выгружается, мейлер устанавливает исходящее соединение, после
 IM> чего удаляет за собой флаг занятости модема. Mgetty, обнаружив что
 IM> такого флага больше нет, запускается новой копией (мы все еще помним про
 IM> режим respawn в inittab?).
 IM>     В твоем же случае, mgetty не видит флага занятости модема, не
 IM> выгружается, а как ни в чем не бывало продолжает его слушать. При этом,
 IM> если мейлер пытается сделать исходящее соединение, mgetty, видимо,
 IM> воспринимает сигналы в порту как руководство к действию и начинает
 IM> управлять модемом. В результате имеем несогласованность работы двух
 IM> софтин, сидящих на одном девайсе. Ну и тот самый геморой, который ты
 IM> описал несколькими письмами ранее.
 IM>     Во всяком случае, мне с моим рабоче-крестьянским образованием такая
 IM> версия развития событий кажется вполне правдоподобной, чтобы проверить
 IM> идентичность путей, по которым разные программы создают флаги занятости
 IM> модемного порта.

  Все примерно правильно, но mgetty не выгружается если кто-то уже
залочил порт, а просто его перестает "слушать".

-- 
                                                  Всего хорошего.
                                                            Андрей.
...Вскрытие показало, что больной - спал.
--- Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17
 * Origin: http://sourceforge.net/projects/rusfidogate (2:467/126)
SEEN-BY: 46/50 400/814 450/1024 462/30 463/614 467/31 61 70 99 112 117 126 127
SEEN-BY: 467/129 469/125 550/357 4615/59 4621/18 4623/56 5000/5000 5010/53
SEEN-BY: 5011/13 5012/46 5015/10 28 5019/31 5020/545 715 2871 4441 5021/29
SEEN-BY: 5025/3 5027/16 5030/115 5035/38 5036/34 5053/16 5054/1 8 9 18 37 45
SEEN-BY: 5054/63 67 81 5059/9 5060/3 5062/10 5063/3 5069/7 5077/70 5080/1003
SEEN-BY: 5085/13 5092/1 5095/20 5096/18 6000/12 254 6001/10

PATH: 467/126 70 46/50 5020/545 5054/1 37