Bug 7519 - inconvience with 'demand' ppp option
: inconvience with 'demand' ppp option
Status: CLOSED NOTABUG
: Sisyphus
(All bugs in Sisyphus/etcnet)
: unstable
: all Linux
: P2 major
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2005-07-30 14:10 by
Modified: 2009-06-17 14:15 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-07-30 14:10:15
При указании опции 'demand' для pppd ifup не завершает свою работу до
момента реальной установки соединения. В комбинации с ONBOOT=yes
загрузка может продлиться неопределённо долго.
------- Comment #1 From 2005-08-01 13:06:53 -------
Предлагается ввести ppp-watch или отложенную конфигурацию из /etc/ppp/ip-up?
------- Comment #2 From 2005-08-04 00:48:03 -------
Принимаю глюк, но пока это особенность дизайна.
------- Comment #3 From 2005-12-22 11:22:00 -------
Помещено в known bugs, но сейчас я не знаю, как это решить.
------- Comment #4 From 2006-04-05 10:38:56 -------
(In reply to comment #3)
> Помещено в known bugs, но сейчас я не знаю, как это решить.

Вариант: убрать из BASIC_PPPOPTIONS "updetach", тогда pppd станет демоном
_сразу_, еще _до_ подключения, что, конечно, может вызвать проблемы у стартующих
после программ, но гарантированно позволит загрузить машину, и, в частности,
после загрузки sshd сделает ее управляемой. :)
------- Comment #5 From 2006-04-05 10:51:25 -------
Мне последний вариант кажется правильным. Вообще, дождаться поднятия интерфейса 
- это проблема того, кому нужен этот интерфейс. Загрузка из-за проблем с любым 
интерфейсом не должна прекращаться ни при каких условиях. Есть, правда, еще 
один вариант, фантастический: кто-то как-то говорил про переход на initng... 
------- Comment #6 From 2006-04-06 09:37:48 -------
Простое исключение updetach нарушит последовательность работы.
Рабочее решение --- убрать опцию demand.
------- Comment #7 From 2006-04-06 11:03:25 -------
(In reply to comment #6)
> Простое исключение updetach нарушит последовательность работы.
> Рабочее решение --- убрать опцию demand.
А причем тут demand? У меня, например, проблема с роутером, у которого опции
"persist" и "maxfal=0", ибо иначе нельзя - его задача - поддерживать PPtP
соединение, и позволять людям работать. И убрать "persist" или "maxfail=0"
НЕЛЬЗЯ - смысла в роутере уже не будет.
------- Comment #8 From 2006-04-06 11:05:15 -------
Т.е. проблема не только в опции "demand". Проблема - в опции "updetach",
которая
при различных конфигурациях может не давать грузиться машинам далее.
------- Comment #9 From 2006-04-06 11:38:20 -------
(In reply to comment #7)
[...]
> А причем тут demand? У меня, например, проблема с роутером, у которого опции
См. оригинальный комментарий.

> "persist" и "maxfal=0", ибо иначе нельзя - его задача - поддерживать PPtP
> соединение, и позволять людям работать. И убрать "persist" или "maxfail=0"
> НЕЛЬЗЯ - смысла в роутере уже не будет.
В чём заключается проблема?
------- Comment #10 From 2006-04-06 19:19:24 -------
> В чём заключается проблема?

В /etc/net/scripts/create-ppp:
# Please don't override BASIC_PPPOPTIONS, if possible.
BASIC_PPPOPTIONS="nolog updetach unit ${NAME//ppp/}"

При 'updetach' pppd будет висеть при загрузке до первого успешного подключения 
и до maxfail, если maxfail=0 && persist, то в случае, если подключение не 
удалось, дальнейшее исполнение rc-скрипта приостанавливается, и sshd не 
стартует, хотя eth0 уже поднят. Следствие - машина неуправляема.


Т.е. роутер, который постоянно (maxfail=0) поддерживает (persist) ppp-соединение
(PPtP, etc), не загрузится, пока это соединение не будет установлено, и не
загрузится совсем, если соединение по какой-то причине установлено быть не
может. Если же "updetach" убрать, то pppd будет висеть демоном, и стучаться
себе, пока позволит maxfail.

И проблема тут одна с описанной изначально. Именно поэтому мне предложили
отписаться сюда.
------- Comment #11 From 2006-04-18 20:09:32 -------
(In reply to comment #10)
> > В чём заключается проблема?
> 
> В /etc/net/scripts/create-ppp:
> # Please don't override BASIC_PPPOPTIONS, if possible.
> BASIC_PPPOPTIONS="nolog updetach unit ${NAME//ppp/}"
> 
> При 'updetach' pppd будет висеть при загрузке до первого успешного 
подключения 
> и до maxfail, если maxfail=0 && persist, то в случае, если подключение не 
> удалось, дальнейшее исполнение rc-скрипта приостанавливается, и sshd не 
> стартует, хотя eth0 уже поднят. Следствие - машина неуправляема.

Все таки если вы в настройках интерфейса указываете ONBOOT=yes, то такое 
поведение конфигуратора сети вполне ожидаемо и предсказуемо, ибо он честно 
пытается поднять все, что ему указали, когда до него доходит очередь при 
загрузке...

> Т.е. роутер, который постоянно (maxfail=0) поддерживает (persist) 
ppp-соединение
> (PPtP, etc), не загрузится, пока это соединение не будет установлено, и не
> загрузится совсем, если соединение по какой-то причине установлено быть не
> может. Если же "updetach" убрать, то pppd будет висеть демоном, и стучаться
> себе, пока позволит maxfail.

Если в задачи роутера не входит настроить _все_ интерфейсы в ходе загрузки, а 
задача стоит загрузиться, а потом "стучаться себе", поддерживая по мере сил 
pptp соединение (я правильно понял ваш случай?), то не будет ли логичнее все 
таки для этого интерфейса ONBOOT=no, а где-нибудь в rc.local 
вставить /sbin/ifup ppp0 ? Такое подойдет решение?

> 
> И проблема тут одна с описанной изначально. Именно поэтому мне предложили
> отписаться сюда.

Пожалуй, все таки, не одно и тоже. Симптомы - да, те же, - остановка загруки 
до установления реального соединения. Но в вашем случае (maxfail=0 persist) 
при этом и интерфейс не поднят, и etcnet законно ждет, пока он либо 
поднимется, либо отвалится. А изначальная проблема отличается тем, что при 
demand интерфейс поднимается и настраивается сразу, и ждать установки 
реального соединения нелогично и пожалуй неправильно.
------- Comment #12 From 2006-04-18 20:36:06 -------
> А изначальная проблема отличается тем, что при 
> demand интерфейс поднимается и настраивается сразу, и ждать установки 
> реального соединения нелогично и пожалуй неправильно.

Поясню комментаторам. Ждать установки соединения при demand и
ONBOOT=yes придётся вечно, поскольку неоткуда взяться трафику,
способному инициировать процедуру установки соединения.
------- Comment #13 From 2006-09-10 02:46:54 -------
Использовать demand напрямую невозможно. Я предлагаю такие интерфейсы поднимать
из crontab и закрыть эту тему.
------- Comment #14 From 2006-09-10 13:15:58 -------
ну так закрывай
------- Comment #15 From 2006-09-10 13:50:39 -------
demand сейчас нельзя использовать в сочетании с ONBOOT=yes, закрываю.