23556 2010-05-30 21:26:56 +0400 PPPoE падает, и подняться не может. 2010-09-21 15:54:27 +0400 1 1 4 Development Sisyphus ppp unstable all Linux CLOSED WONTFIX P3 normal --- 1 MisHel64 nobody MisHel64 asy cas mike pilot sem qa-sisyphus oldest_to_newest 109555 0 MisHel64 2010-05-30 21:26:56 +0400 Здравствуйте. Давно было подозрение, что 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 === 109556 1 raorn 2010-05-30 21:45:53 +0400 Это нормальное поведение 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 *** 109558 2 MisHel64 2010-05-30 22:53:45 +0400 Ну во первых данная ошибки ни коем образом не дублирует ошибку 12382. Во вторых, все написанное вами не имеет отношения к проблеме. В третьих, еще год назад все нормально работало. Что, где и когда поломали точнее затрудняюсь ответить. Долго не пользовался продукцией альтов. Я правильно понял смысл вашего ответа, не только чинить, но иразбиратся в вопросе никто не будет, и единственное решение, это приделать костыли? 109839 3 mike 2010-06-12 12:08:15 +0400 (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. 111372 4 asy 2010-08-22 23:35:56 +0400 (In reply to comment #2) > Я правильно понял смысл вашего ответа, не только чинить, но иразбиратся в > вопросе никто не будет, и единственное решение, это приделать костыли? В чём разбираться ? Написано же: "maxfail 3". Три раза тыкнулся, потом отпал. Или речь уже про фоновый старт pppd ? 111384 5 MisHel64 2010-08-23 11:00:29 +0400 Он один раз пытается подняться, и поднимается, а потом еще не отработавшим до конца скриптом /etc/ppp/ip-down прибивается, что отчетливо видно из приведенного лога. Демон считает, что соединение установлено нормально, больше не пытается его поднять. А фактически оно прибито и отсутствует. Значение maxfail 3 ему по барабану в этом случае. 111392 6 asy 2010-08-23 15:50:07 +0400 (In reply to comment #5) > Он один раз пытается подняться, и поднимается, а потом еще не отработавшим до > конца скриптом /etc/ppp/ip-down прибивается, Чем-чем прибивается ?! :-) > что отчетливо видно из приведенного лога. Не видно: ip-down совсем не для этого, изучите pppd. По-умолчанию, кстати, в ip-down пусто. > Демон считает, что соединение установлено нормально, больше > не пытается его поднять. А фактически оно прибито и отсутствует. Скорее оно не поднято по какой-то причине. > Значение maxfail 3 ему по барабану в этом случае. "lcp-echo-failure 3" и "lcp-echo-interval 20", вообще-то, должны заставить демона поверить в смерть соединения... Что-то тут не так, но это что-то - совсем другое. 111397 7 MisHel64 2010-08-23 16:28:15 +0400 (В ответ на комментарий №6) > (In reply to comment #5) > > > Он один раз пытается подняться, и поднимается, а потом еще не отработавшим до > > конца скриптом /etc/ppp/ip-down прибивается, > > Чем-чем прибивается ?! :-) Тем, чем я сказал. Логи приведенные в первом посте. > > что отчетливо видно из приведенного лога. > > Не видно: ip-down совсем не для этого, изучите pppd. По-умолчанию, кстати, в > ip-down пусто. В этом по умолчанию постом файле 60 строк. И вызовы других скриптов. > > Демон считает, что соединение установлено нормально, больше > > не пытается его поднять. А фактически оно прибито и отсутствует. > > Скорее оно не поднято по какой-то причине. Оно поднято, что видно из логов. Логи приведены в первом посте. Посмотрите пожалуйста их с начало. 111398 8 asy 2010-08-23 16:37:41 +0400 (In reply to comment #7) > > > конца скриптом /etc/ppp/ip-down прибивается, > > > > Чем-чем прибивается ?! :-) > > Тем, чем я сказал. Логи приведенные в первом посте. Нет. > > Не видно: ip-down совсем не для этого, изучите pppd. По-умолчанию, кстати, в > > ip-down пусто. > > В этом по умолчанию постом файле 60 строк. И вызовы других скриптов. Да, правда. Подрос файлик. Тем не менее, там нет ничего, что относилось бы к прибиванию линка. Ещё раз, почитайте назначение скрипта, затем посмотрите, что именно он делает. > > Скорее оно не поднято по какой-то причине. > > Оно поднято, что видно из логов. По логу видно, что поднятно, не спорю. Вопрос, что по факту - это раз, какой syslog - это два. А то, может, он просто не дописал ? > Логи приведены в первом посте. Посмотрите пожалуйста их с начало. Я видел. Вы их неправильно интерпретируете, по крайней мере, в районе понимания функций скрипта ip-down. 111399 9 MisHel64 2010-08-23 17:03:18 +0400 (В ответ на комментарий №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. Сомневаюсь, что именно я не правильно интерпретирую. 111400 10 4504 MisHel64 2010-08-23 17:06:02 +0400 Created attachment 4504 ifdown-ppp 111401 11 4505 MisHel64 2010-08-23 17:06:53 +0400 Created attachment 4505 ip-down 111402 12 asy 2010-08-23 17:35:55 +0400 (In reply to comment #9) > Вызывает /etc/net/scripts/ifdown-ppp Блин, просмотрел. Действительно вызывает. Тогда вопрос к автору изменения, какова цель этого действия. Что-то я, пока, сообразить не могу. 111403 13 MisHel64 2010-08-23 17:48:25 +0400 То, что вызывает, это не страшно, и IMHO нужно. А вот то, что начинает устанавливать новое соединение, до завершения работы скрипта от старого, вот не кошерно, и порождает уже около года ошибку. Да уж, скоро три месяца как бага висит... 111404 14 asy 2010-08-23 18:04:15 +0400 (In reply to comment #13) > То, что вызывает, это не страшно, и IMHO нужно. Зачем ? > А вот то, что начинает устанавливать новое соединение, до завершения работы > скрипта от старого, вот не кошерно, и порождает уже около года ошибку. На сколько я понимаю, это просто особенность pppd. А когда-то давно не вызывался ifdown-ppp. Хотя вот сейчас смотрю, это есть ешё в ppp-common-0.4.2-alt1, который входил в 4.0. 111405 15 asy 2010-08-23 18:12:13 +0400 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 успевает реконект до его завершения сделать, а завершения вовсе не ждёт. 111407 16 MisHel64 2010-08-23 18:40:26 +0400 (В ответ на комментарий №14) > (In reply to comment #13) > > > То, что вызывает, это не страшно, и IMHO нужно. > > Зачем ? Не знаю. Наверное нужно, что бы убрать что нибудь. > > А вот то, что начинает устанавливать новое соединение, до завершения работы > > скрипта от старого, вот не кошерно, и порождает уже около года ошибку. > > На сколько я понимаю, это просто особенность pppd. А когда-то давно не > вызывался ifdown-ppp. Хотя вот сейчас смотрю, это есть ешё в > ppp-common-0.4.2-alt1, который входил в 4.0. В ALS401 это работало нормально, по крайней мере в мае прошлого года у меня подобной проблемы не было. Информация об этом странном поведении промелькнула прошлым летом в рассылках. Я то же наступив на эти грабли, не стал разбираться, перенес PPPd на железный роутер. 111408 17 MisHel64 2010-08-23 18:43:54 +0400 (В ответ на комментарий №15) > Судя по логу, pppd успевает реконект до его завершения > сделать, а завершения вовсе не ждёт. А я это еще в пятом комментарии писал. А вы мне не верили. 111411 18 asy 2010-08-23 19:17:05 +0400 (In reply to comment #17) > > Судя по логу, pppd успевает реконект до его завершения > > сделать, а завершения вовсе не ждёт. > > А я это еще в пятом комментарии писал. А вы мне не верили. Я не верил, что в ip-down вызывается что-то, что влияет на сам pppd. 112460 19 asy 2010-09-21 15:53:10 +0400 Думаю, надо закрыть этот баг в пользу двух других, так как тут смысл уже теряется за написанным. Bug #24130 Bug #24131 4504 2010-08-23 17:06:02 +0400 2010-08-23 17:06:02 +0400 ifdown-ppp ifdown-ppp text/plain 1210 MisHel64 IyEvYmluL2Jhc2gKCiMgVGhpcyBzY3JpcHQgc2hvdWxkIGJlIGNhbGxlZCB3aGVuIHBwcCBsaW5r IGdvZXMgZG93biwgdGhlIG1vc3QKIyBuYXR1cmFsIHdheSB0byBkbyBpdCBpcyB0byBoYXZlIGEg aG9vayBpbiAvZXRjL3BwcC9pcC1kb3duLmQKIyBkaXJlY3RvcnkuIFRoaXMgc2NyaXB0cyBpcyBu b3QgaW50ZW5kZWQgdG8gYmUgcnVuIGRpcmVjdGx5LAojIG9uZSBzaG91bGQgdXNlIGlmZG93biB0 byBzaHV0ZG93biBhIHBwcCBsaW5rLgoKdXNhZ2UoKQp7CgllY2hvICJVc2FnZTogJDAgPGludGVy ZmFjZT4iID4mMgoJZXhpdCAxCn0KClsgLXogIiQxIiBdICYmIHVzYWdlCk5BTUU9JDEKClsgLXog IiRTQ1JJUFRESVIiIF0gJiYgLiAke1NDUklQVERJUjo9L2V0Yy9uZXQvc2NyaXB0c30vZnVuY3Rp b25zCnBpY2t1cF9kZWZhdWx0cwppZiBbIC1kICRJRkFDRURJUi8kTkFNRUAkTkVUSE9TVCBdOyB0 aGVuCglNWUlGQUNFRElSPSRJRkFDRURJUi8kTkFNRUAkTkVUSE9TVAplbHNlCglNWUlGQUNFRElS PSRJRkFDRURJUi8kTkFNRQpmaQpleHBvcnQgSUZBQ0VESVIgTVlJRkFDRURJUiBTQ1JJUFRESVIg TkFNRSBTRUVOX0lGQUNFUwoKaW5pdF9uZXRwcm9maWxlCnBpY2t1cF9vcHRpb25zCnNlZW5faWZh Y2UgJE5BTUUgJiYgZXhpdCAwCmFkZF9zZWVuX2lmYWNlICROQU1FCgojIGNvbW1vbiBwYXJ0Cmlm ZG93bl9jaGlsZHJlbgoKaWYgaWZhY2VfaXNfdXAgJE5BTUU7IHRoZW4KCUV4ZWNJZkV4ZWN1dGFi bGUgJExPQ0FMU0NSSVBURElSL2lmZG93bi1wcmUtbG9jYWwgJE5BTUUgJiYgcHJpbnRfcHJvZ3Jl c3MKCUV4ZWNJZkV4ZWN1dGFibGUgJE1ZSUZBQ0VESVIvaWZkb3duLXByZSAkTkFNRSAmJiBwcmlu dF9wcm9ncmVzcwoJJElQIGxpbmsgc2V0IGRldiAkTkFNRSBkb3duCmZpCgppZiBpc195ZXMgIiRS RVNUT1JFX0RFRkFVTFRST1VURSIgJiYgWyAtcyAvdmFyL3J1bi8kTkFNRS5kZWZhdWx0cm91dGUg XTsgdGhlbgoJeGFyZ2lzZV9maWxlIC92YXIvcnVuLyROQU1FLmRlZmF1bHRyb3V0ZSAiJElQIHJv IGFkIgoJcm0gLWYgL3Zhci9ydW4vJE5BTUUuZGVmYXVsdHJvdXRlCmZpCgpFeGVjSWZFeGVjdXRh YmxlICRMT0NBTFNDUklQVERJUi9pZmRvd24tcG9zdC1sb2NhbCAkTkFNRSAmJiBwcmludF9wcm9n cmVzcwpFeGVjSWZFeGVjdXRhYmxlICRNWUlGQUNFRElSL2lmZG93bi1wb3N0ICROQU1FICYmIHBy aW50X3Byb2dyZXNzCg== 4505 2010-08-23 17:06:53 +0400 2010-08-23 17:06:53 +0400 ip-down ip-down text/plain 1418 MisHel64 IyEvYmluL3NoCgojIFRoaXMgZmlsZSBzaG91bGQgbm90IGJlIG1vZGlmaWVkIC0tIG1ha2UgbG9j YWwgY2hhbmdlcyB0bwojIC9ldGMvcHBwL2lwLWRvd24ubG9jYWwgaW5zdGVhZAoKIyBGcm9tIHBw cGQgbWFucGFnZToKCiMgICAgICAgL2V0Yy9wcHAvaXAtZG93bgojICAgICAgICAgICAgICBBIHBy b2dyYW0gb3Igc2NyaXB0IHdoaWNoIGlzIGV4ZWN1dGVkIHdoZW4gdGhlIGxpbmsgaXMgbm8gbG9u Z2VyCiMgICAgICAgICAgICAgIGF2YWlsYWJsZSBmb3Igc2VuZGluZyBhbmQgcmVjZWl2aW5nIElQ IHBhY2tldHMuICBUaGlzIHNjcmlwdCBjYW4KIyAgICAgICAgICAgICAgYmUgIHVzZWQgIGZvciAg dW5kb2luZyB0aGUgZWZmZWN0cyBvZiB0aGUgL2V0Yy9wcHAvaXAtdXAgc2NyaXB0LgojICAgICAg ICAgICAgICBJdCBpcyBpbnZva2VkIGluIHRoZSBzYW1lIG1hbm5lciBhbmQgd2l0aCB0aGUgc2Ft ZSBwYXJhbWV0ZXJzIGFzCiMgICAgICAgICAgICAgIHRoZSBpcC11cCBzY3JpcHQuCgpMT0dERVZJ Q0U9JDYKUkVBTERFVklDRT0kMQpSRVNPTFZDT05GPS9zYmluL3Jlc29sdmNvbmYKCmV4cG9ydCBQ QVRIPS9zYmluOi91c3Ivc2JpbjovYmluOi91c3IvYmluCgppZiBbIC1mIC9ldGMvcmVzb2x2LmNv bmYuc2F2ZS4kUkVBTERFVklDRSBdOyB0aGVuCgljYXQgL2V0Yy9yZXNvbHYuY29uZi5zYXZlLiRS RUFMREVWSUNFID4vZXRjL3Jlc29sdi5jb25mCglybSAtZiAvZXRjL3Jlc29sdi5jb25mLnNhdmUu JFJFQUxERVZJQ0UKCVVDPS91c3Ivc2Jpbi91cGRhdGVfY2hyb290ZWQKCVsgLXggJFVDIF0gJiYg JFVDIGNvbmYKZWxzZQoJWyAteCAiJFJFU09MVkNPTkYiIF0gJiYgJFJFU09MVkNPTkYgLWZkICRS RUFMREVWSUNFCmZpCgpmb3IgZiBpbiAvZXRjL3BwcC9pcC1kb3duLmQvKjsgZG8KCVsgLXggIiRm IiBdIHx8IGNvbnRpbnVlCgoJIyBEb24ndCBydW4gKi5ycG0qIGFuZCAqfiBzY3JpcHRzCglbICIk e2YlLnJwbSp9IiA9ICIkZiIgLWEgIiR7ZiVcfn0iID0gIiRmIiBdIHx8IGNvbnRpbnVlCgoJIiRm IiAiJEAiCmRvbmUKCklQX0RPV05fTE9DQUw9L2V0Yy9wcHAvaXAtZG93bi5sb2NhbApbIC14ICIk SVBfRE9XTl9MT0NBTCIgXSAmJiAiJElQX0RPV05fTE9DQUwiICIkQCIKCkVUQ05FVF9JRkRPV049 L2V0Yy9uZXQvc2NyaXB0cy9pZmRvd24tcHBwCk5TX0lGRE9XTj0vZXRjL3N5c2NvbmZpZy9uZXR3 b3JrLXNjcmlwdHMvaWZkb3duLXBvc3QKTl9DX1NfQ09ORklHPS9ldGMvc3lzY29uZmlnL25ldHdv cmsKCi4gJE5fQ19TX0NPTkZJRwoKY2FzZSAkQ09ORk1FVEhPRCBpbgoJZXRjbmV0KQoJCWV4ZWMg JEVUQ05FVF9JRkRPV04gJFJFQUxERVZJQ0UKCTs7CgluZXQtc2NyaXB0cykKCQlleGVjICROU19J RkRPV04gImlmY2ZnLSRMT0dERVZJQ0UiCgk7OwoJKikKCTs7CmVzYWMKCmV4aXQgMAo=