При указании опции 'demand' для pppd ifup не завершает свою работу до момента реальной установки соединения. В комбинации с ONBOOT=yes загрузка может продлиться неопределённо долго.
Предлагается ввести 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, закрываю.
