Предлагается ввести ppp-watch или отложенную конфигурацию из /etc/ppp/ip-up?

Принимаю глюк, но пока это особенность дизайна.

Помещено в known bugs, но сейчас я не знаю, как это решить.

(In reply to comment #3)
> Помещено в known bugs, но сейчас я не знаю, как это решить.

Вариант: убрать из BASIC_PPPOPTIONS "updetach", тогда pppd станет демоном
_сразу_, еще _до_ подключения, что, конечно, может вызвать проблемы у стартующих
после программ, но гарантированно позволит загрузить машину, и, в частности,
после загрузки sshd сделает ее управляемой. :)

Мне последний вариант кажется правильным. Вообще, дождаться поднятия интерфейса 
- это проблема того, кому нужен этот интерфейс. Загрузка из-за проблем с любым 
интерфейсом не должна прекращаться ни при каких условиях. Есть, правда, еще 
один вариант, фантастический: кто-то как-то говорил про переход на initng... 
 

Простое исключение updetach нарушит последовательность работы.
Рабочее решение --- убрать опцию demand.

(In reply to comment #6)
> Простое исключение updetach нарушит последовательность работы.
> Рабочее решение --- убрать опцию demand.
А причем тут demand? У меня, например, проблема с роутером, у которого опции
"persist" и "maxfal=0", ибо иначе нельзя - его задача - поддерживать PPtP
соединение, и позволять людям работать. И убрать "persist" или "maxfail=0"
НЕЛЬЗЯ - смысла в роутере уже не будет.

Т.е. проблема не только в опции "demand". Проблема - в опции "updetach", которая
при различных конфигурациях может не давать грузиться машинам далее.

(In reply to comment #7)
[...]
> А причем тут demand? У меня, например, проблема с роутером, у которого опции
См. оригинальный комментарий.

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

> В чём заключается проблема?

В /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.

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

(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 интерфейс поднимается и настраивается сразу, и ждать установки 
реального соединения нелогично и пожалуй неправильно.

> А изначальная проблема отличается тем, что при 
> demand интерфейс поднимается и настраивается сразу, и ждать установки 
> реального соединения нелогично и пожалуй неправильно.

Поясню комментаторам. Ждать установки соединения при demand и
ONBOOT=yes придётся вечно, поскольку неоткуда взяться трафику,
способному инициировать процедуру установки соединения.

Использовать demand напрямую невозможно. Я предлагаю такие интерфейсы поднимать
из crontab и закрыть эту тему.

ну так закрывай

demand сейчас нельзя использовать в сочетании с ONBOOT=yes, закрываю.