ALT Linux Bugzilla – #23556

Это нормальное поведение 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