Здравствуйте. Давно было подозрение, что PPPoE при планом "разрыве" падает и не поднимается. Вот выдержка из логов: May 29 14:26:18 hsrv pppoe[6143]: Session 7209 terminated -- received PADT from peer May 29 14:26:18 hsrv pppd[6146]: LCP terminated by peer May 29 14:26:18 hsrv pppd[6146]: Connect time 1440.0 minutes. May 29 14:26:18 hsrv pppd[6146]: Sent 1803714512 bytes, received 1122830342 bytes. May 29 14:26:18 hsrv pppoe[6143]: Sent PADT May 29 14:26:18 hsrv pppd[6146]: Modem hangup May 29 14:26:18 hsrv pppd[6146]: Connection terminated. May 29 14:26:18 hsrv pppd[6146]: Using interface ppp10 May 29 14:26:18 hsrv pppd[6146]: Connect: ppp10 <--> /dev/pts/1 May 29 14:26:18 hsrv pppoe[5010]: PPP session is 10877 (0x2a7d) May 29 14:26:18 hsrv pppd[6146]: Remote message: Authentication success,Welcome! May 29 14:26:18 hsrv pppd[6146]: PAP authentication succeeded May 29 14:26:18 hsrv pppd[6146]: local IP address 95.68.188.233 May 29 14:26:18 hsrv pppd[6146]: remote IP address 89.239.189.2 May 29 14:26:18 hsrv pppd[6146]: primary DNS address 89.239.139.130 May 29 14:26:18 hsrv pppd[6146]: secondary DNS address 89.239.139.131 May 29 14:26:19 hsrv pppd[6146]: Script /etc/ppp/ip-down finished (pid 5002), status = 0x1 May 29 14:26:19 hsrv pppd[6146]: Script /etc/ppp/ip-up finished (pid 5110), status = 0x0 После разрыва соединения, который виден в логе, интерфейс PPP10 исчез из системы. Конфиги привожу ниже. Ткните носом, что я делаю не так. Сервер 4.0.1, бранч 5.1 options === TYPE=ppp PPPTYPE=pppoe DISABLED=no ONBOOT=no CONFIG_QOS=no CONFIG_FW=no NM_CONTROLLED=no HOST=emod === pppoptions === persist maxfail 3 noipdefault default-asyncmap defaultroute hide-password refuse-chap usepeerdns noaccomp noccp nobsdcomp nodeflate nopcomp novj novjccomp name XXXXXXXXXXXXXXXX linkname mvc lcp-echo-failure 3 lcp-echo-interval 20 ===
Это нормальное поведение pppd. Для невозбранного достижения желаемого надо использовать опции persist и maxfail 0 (а не 3), но тогда будет зависание во время загрузки, если по каким-то причинам ppp соединения не может подняться. Единственный рабочий вариант на сегодняшний день - строчка в /etc/crontab: * * * * * root [ -s /var/run/pppN.pid ] || ifup pppN Но лучше всего таки пропатчить pppd, чтобы при persist и maxfail 0 он не зависал на старте. *** This bug has been marked as a duplicate of bug 12382 ***
Ну во первых данная ошибки ни коем образом не дублирует ошибку 12382. Во вторых, все написанное вами не имеет отношения к проблеме. В третьих, еще год назад все нормально работало. Что, где и когда поломали точнее затрудняюсь ответить. Долго не пользовался продукцией альтов. Я правильно понял смысл вашего ответа, не только чинить, но иразбиратся в вопросе никто не будет, и единственное решение, это приделать костыли?
(In reply to comment #1) > Но лучше всего таки пропатчить pppd, чтобы при persist и maxfail 0 он не > зависал на старте. Поискал -- наскоро (ppp persist maxfail patch) ничего не нашлось. А что, у нас и сейчас ppp* поднимается не в фоне? (давно не сталкивался из etcnet, через трубы звоню своим скриптом) (In reply to comment #2) > Я правильно понял смысл вашего ответа, не только чинить, но и разбиратся в > вопросе никто не будет Скажем так -- из майнтейнеров действительно некому. > и единственное решение, это приделать костыли? Вполне энтерпрайзно... ещё один испытанный вариант -- строчка в /etc/inittab: http://lists.altlinux.org/pipermail/community/2001-January/422459.html На самом деле перезвон -- старое больное место. См., например, bug #10095, bug #8312 или bug #1589.
(In reply to comment #2) > Я правильно понял смысл вашего ответа, не только чинить, но иразбиратся в > вопросе никто не будет, и единственное решение, это приделать костыли? В чём разбираться ? Написано же: "maxfail 3". Три раза тыкнулся, потом отпал. Или речь уже про фоновый старт pppd ?
Он один раз пытается подняться, и поднимается, а потом еще не отработавшим до конца скриптом /etc/ppp/ip-down прибивается, что отчетливо видно из приведенного лога. Демон считает, что соединение установлено нормально, больше не пытается его поднять. А фактически оно прибито и отсутствует. Значение maxfail 3 ему по барабану в этом случае.
(In reply to comment #5) > Он один раз пытается подняться, и поднимается, а потом еще не отработавшим до > конца скриптом /etc/ppp/ip-down прибивается, Чем-чем прибивается ?! :-) > что отчетливо видно из приведенного лога. Не видно: ip-down совсем не для этого, изучите pppd. По-умолчанию, кстати, в ip-down пусто. > Демон считает, что соединение установлено нормально, больше > не пытается его поднять. А фактически оно прибито и отсутствует. Скорее оно не поднято по какой-то причине. > Значение maxfail 3 ему по барабану в этом случае. "lcp-echo-failure 3" и "lcp-echo-interval 20", вообще-то, должны заставить демона поверить в смерть соединения... Что-то тут не так, но это что-то - совсем другое.
(В ответ на комментарий №6) > (In reply to comment #5) > > > Он один раз пытается подняться, и поднимается, а потом еще не отработавшим до > > конца скриптом /etc/ppp/ip-down прибивается, > > Чем-чем прибивается ?! :-) Тем, чем я сказал. Логи приведенные в первом посте. > > что отчетливо видно из приведенного лога. > > Не видно: ip-down совсем не для этого, изучите pppd. По-умолчанию, кстати, в > ip-down пусто. В этом по умолчанию постом файле 60 строк. И вызовы других скриптов. > > Демон считает, что соединение установлено нормально, больше > > не пытается его поднять. А фактически оно прибито и отсутствует. > > Скорее оно не поднято по какой-то причине. Оно поднято, что видно из логов. Логи приведены в первом посте. Посмотрите пожалуйста их с начало.
(In reply to comment #7) > > > конца скриптом /etc/ppp/ip-down прибивается, > > > > Чем-чем прибивается ?! :-) > > Тем, чем я сказал. Логи приведенные в первом посте. Нет. > > Не видно: ip-down совсем не для этого, изучите pppd. По-умолчанию, кстати, в > > ip-down пусто. > > В этом по умолчанию постом файле 60 строк. И вызовы других скриптов. Да, правда. Подрос файлик. Тем не менее, там нет ничего, что относилось бы к прибиванию линка. Ещё раз, почитайте назначение скрипта, затем посмотрите, что именно он делает. > > Скорее оно не поднято по какой-то причине. > > Оно поднято, что видно из логов. По логу видно, что поднятно, не спорю. Вопрос, что по факту - это раз, какой syslog - это два. А то, может, он просто не дописал ? > Логи приведены в первом посте. Посмотрите пожалуйста их с начало. Я видел. Вы их неправильно интерпретируете, по крайней мере, в районе понимания функций скрипта ip-down.
(В ответ на комментарий №8) > (In reply to comment #7) > > > > > конца скриптом /etc/ppp/ip-down прибивается, > > > > > > Чем-чем прибивается ?! :-) > > > > Тем, чем я сказал. Логи приведенные в первом посте. > > Нет. А я проверял. Если /etc/ppp/ip-down заканчивается раньше, судя по логам, то соединение устанавливается и работает нормально. Даже простейший пример. Делаю # ifdown # ifup И все отлично работает. > > > Не видно: ip-down совсем не для этого, изучите pppd. По-умолчанию, кстати, в > > > ip-down пусто. > > > > В этом по умолчанию постом файле 60 строк. И вызовы других скриптов. > > Да, правда. Подрос файлик. Тем не менее, там нет ничего, что относилось бы к > прибиванию линка. Вы не правы. > Ещё раз, почитайте назначение скрипта, затем посмотрите, что > именно он делает. Посмотрел. Вызывает /etc/net/scripts/ifdown-ppp А тот $IP link set dev $NAME down > > > Скорее оно не поднято по какой-то причине. > > > > Оно поднято, что видно из логов. > > По логу видно, что поднятно, не спорю. Вопрос, что по факту - это раз, какой > syslog - это два. Обычный сислог "из коробки". Локальный, если вы на это намекаете. > > Логи приведены в первом посте. Посмотрите пожалуйста их с начало. > > Я видел. Вы их неправильно интерпретируете, по крайней мере, в районе понимания > функций скрипта ip-down. Сомневаюсь, что именно я не правильно интерпретирую.
Created attachment 4504 [details] ifdown-ppp
Created attachment 4505 [details] ip-down
(In reply to comment #9) > Вызывает /etc/net/scripts/ifdown-ppp Блин, просмотрел. Действительно вызывает. Тогда вопрос к автору изменения, какова цель этого действия. Что-то я, пока, сообразить не могу.
То, что вызывает, это не страшно, и IMHO нужно. А вот то, что начинает устанавливать новое соединение, до завершения работы скрипта от старого, вот не кошерно, и порождает уже около года ошибку. Да уж, скоро три месяца как бага висит...
(In reply to comment #13) > То, что вызывает, это не страшно, и IMHO нужно. Зачем ? > А вот то, что начинает устанавливать новое соединение, до завершения работы > скрипта от старого, вот не кошерно, и порождает уже около года ошибку. На сколько я понимаю, это просто особенность pppd. А когда-то давно не вызывался ifdown-ppp. Хотя вот сейчас смотрю, это есть ешё в ppp-common-0.4.2-alt1, который входил в 4.0.
2pilot: Судя по http://git.altlinux.org/people/ldv/packages/?p=ppp-common.git;a=commitdiff;h=bbb997a85edf3da618349b3ecb05aa6443f97993 оно там изначально. Не вспомнишь, зачем +case $CONFMETHOD in + etcnet) + # Just do nothing atm (no ppp support in /etc/net). +# exec $ETCNET_IFDOWN $REALDEVICE + ;; + *) + exec $NS_IFDOWN "ifcfg-$LOGDEVICE" + ;; +esac в /etc/ppp/ip-down ? Судя по логу, pppd успевает реконект до его завершения сделать, а завершения вовсе не ждёт.
(В ответ на комментарий №14) > (In reply to comment #13) > > > То, что вызывает, это не страшно, и IMHO нужно. > > Зачем ? Не знаю. Наверное нужно, что бы убрать что нибудь. > > А вот то, что начинает устанавливать новое соединение, до завершения работы > > скрипта от старого, вот не кошерно, и порождает уже около года ошибку. > > На сколько я понимаю, это просто особенность pppd. А когда-то давно не > вызывался ifdown-ppp. Хотя вот сейчас смотрю, это есть ешё в > ppp-common-0.4.2-alt1, который входил в 4.0. В ALS401 это работало нормально, по крайней мере в мае прошлого года у меня подобной проблемы не было. Информация об этом странном поведении промелькнула прошлым летом в рассылках. Я то же наступив на эти грабли, не стал разбираться, перенес PPPd на железный роутер.
(В ответ на комментарий №15) > Судя по логу, pppd успевает реконект до его завершения > сделать, а завершения вовсе не ждёт. А я это еще в пятом комментарии писал. А вы мне не верили.
(In reply to comment #17) > > Судя по логу, pppd успевает реконект до его завершения > > сделать, а завершения вовсе не ждёт. > > А я это еще в пятом комментарии писал. А вы мне не верили. Я не верил, что в ip-down вызывается что-то, что влияет на сам pppd.
Думаю, надо закрыть этот баг в пользу двух других, так как тут смысл уже теряется за написанным. Bug #24130 Bug #24131