По логу в рассылке это похоже на локальную проблему. А именно, кто-то после поднятия туннеля шлёт SIGHUP процессу pppd. Кто это - надо искать на месте.

Поискал у себя на машинах - ничего такого не вижу, pppd работает без проблем. x86_64/systemd и i586/sysvinit, NM нигде нету.

(В ответ на комментарий №1)
> Кто-то после поднятия туннеля шлёт SIGHUP процессу pppd.

А можно ли узнать, кто именно шлет этот самый SIGHUP? В рассылке я отписал, что указание `nodetach' в опциях pppd частично решает проблему. А именно, после этого `ifup ppp0', конечно же, не завершается, но и разъединения не происходит. Достаточно просто запустить `ifup ppp0 &', то есть, в фоне.

> Кто это - надо искать на месте.

Какой журнал смотреть? Вот, например, фрагмент /var/log/messages при включенных опциях pppd `dump' и `debug':

Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: pppd options in effect:
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: debug^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: updetach^I^I# (from command line)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: nolog^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: unit 0^I^I# (from command line)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: dump^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: noauth^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: user gdata^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: password ??????^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: /dev/ttyACM0^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: lock^I^I# (from /etc/ppp/options)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: connect /usr/sbin/chat -t 120 -f /etc/net/ifaces/ppp0/pppconnect^I^I# (from command line)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: disconnect /usr/sbin/chat -t 120 -f /etc/net/ifaces/ppp0/pppdisconnect^I^I# (from command line)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: modem^I^I# (from command line)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: noaccomp^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: nopcomp^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: lcp-echo-failure 0^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: lcp-echo-interval 0^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: receive-all^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: novj^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: novjccomp^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: noipdefault^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: defaultroute^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: replacedefaultroute^I^I# (from /etc/ppp/options)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: usepeerdns^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: :10.6.6.6^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: nobsdcomp^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: nodeflate^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 08:55:53 comp-celeron-cpu-3a87ac pppd[3255]: pppd 2.4.5 started by maverik, uid 0
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: Script /usr/sbin/chat -t 120 -f /etc/net/ifaces/ppp0/pppconnect finished (pid 3256), status = 0x0
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: Serial connection established.
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: Using interface ppp0
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: Connect: ppp0 <--> /dev/ttyACM0
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: replacing old default route to eth1 [192.168.0.2]
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: local  IP address xxx.xxx.xxx.xxx
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: remote IP address 10.6.6.6
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: primary   DNS address xxx.xxx.xxx.xxx
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3255]: secondary DNS address xxx.xxx.xxx.xxx
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: Hangup (SIGHUP)
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: Modem hangup
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: Connect time 0.0 minutes.
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: Sent 0 bytes, received 0 bytes.
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: restoring old default route to eth1 [192.168.0.2]
Nov  6 08:55:56 comp-celeron-cpu-3a87ac pppd[3259]: Connection terminated.
Nov  6 08:55:57 comp-celeron-cpu-3a87ac pppd[3259]: Script /etc/ppp/ip-up finished (pid 3260), status = 0x0
Nov  6 08:55:58 comp-celeron-cpu-3a87ac pppd[3259]: Script /etc/ppp/ip-down finished (pid 3376), status = 0x1
Nov  6 08:55:58 comp-celeron-cpu-3a87ac pppd[3259]: Exit.

Как еще проверить, кто именно шлет сигнал на остановку? И опять же, включение опции `detach' не разрывает соединения. Сравните:

Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: pppd options in effect:
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: debug^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: nodetach^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: nolog^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: unit 0^I^I# (from command line)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: dump^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: noauth^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: user gdata^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: password ??????^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: /dev/ttyACM0^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: lock^I^I# (from /etc/ppp/options)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: connect /usr/sbin/chat -t 120 -f /etc/net/ifaces/ppp0/pppconnect^I^I# (from command line)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: disconnect /usr/sbin/chat -t 120 -f /etc/net/ifaces/ppp0/pppdisconnect^I^I# (from command line)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: modem^I^I# (from command line)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: noaccomp^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: nopcomp^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: lcp-echo-failure 0^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: lcp-echo-interval 0^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: receive-all^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: novj^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: novjccomp^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: noipdefault^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: defaultroute^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: replacedefaultroute^I^I# (from /etc/ppp/options)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: usepeerdns^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: :10.6.6.6^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: nobsdcomp^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: nodeflate^I^I# (from /etc/net/ifaces/ppp0/pppoptions)
Nov  6 09:01:47 comp-celeron-cpu-3a87ac pppd[3607]: pppd 2.4.5 started by maverik, uid 0
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: Script /usr/sbin/chat -t 120 -f /etc/net/ifaces/ppp0/pppconnect finished (pid 3608), status = 0x0
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: Serial connection established.
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: Using interface ppp0
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: Connect: ppp0 <--> /dev/ttyACM0
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: replacing old default route to eth1 [192.168.0.2]
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: local  IP address xxx.xxx.xxx.xxx
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: remote IP address 10.6.6.6
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: primary   DNS address xxx.xxx.xxx.xxx
Nov  6 09:01:50 comp-celeron-cpu-3a87ac pppd[3607]: secondary DNS address xxx.xxx.xxx.xxx
Nov  6 09:01:51 comp-celeron-cpu-3a87ac pppd[3607]: Script /etc/ppp/ip-up finished (pid 3612), status = 0x0

> NM нигде нету.

Ну и у меня, похоже, нету. Значит, проблема все же в etcnet?

попробуйте поотлажитвать с помощью audit
включить полное протоколирование действий над процессом pppd и посмотреть от кого получен сигнал.

Путем упрощения ситуации удалось выяснить, что etcnet тут вообще ни при чем. И проблема именно в pppd и именно такая, как описано в рассылке

http://lists.altlinux.org/pipermail/community/2014-November/682884.html

По сути можно запустить просто из консоли

/usr/sbin/pppd file /etc/net/ifaces/ppp0/pppoptions connect '/usr/sbin/chat -t 15 -f /etc/net/ifaces/ppp0/pppconnect' disconnect '/usr/sbin/chat -t 15 -f /etc/net/ifaces/ppp0/pppdisconnect'

и все будет работать. Если в точности ту же строку поместить в скрипт, например, ppp-test.sh и исполнить его в командной строке, то pppd будет завершен аварийно. Файлы, относящиеся к этому примеру я выложу дополнительно.

Created attachment 6165 [details]
Комплект настроек ppp0 для etcnet

Created attachment 6166 [details]
Сценарий, при запуске которого pppd сразу закрывает соединение

Created attachment 6167 [details]
Результат autrace pppd из консоли

Created attachment 6168 [details]
Результат autrace pppd из сценария

Похоже, когда pppd запускается из сценария, он работает в новом окружении. При завершении сценария bash закрывает окружение и вызванный pppd. Пока что нет времени еще больше упростить задачу и поиграть с возможностями eval/exec в сценарии.

Кроме того, autrace для меня --- темный лес. Приложил журналы трассировки, но в обоих есть вызов SIGHUP. К тому же, я так и не понял, кто вызывает SIGHUP для pppd. Пожалуйста, помогите в интерпретации журналов. Возможно, нужны более тонкие опции autrace, подскажите, если нужно.

Продолжение следует...

Да, проблема именно в запуске pppd в новом окружении. То есть, для воспроизведения проблемы достаточно запустить из командной строки следующим образом:

# $(/usr/sbin/pppd file /etc/net/ifaces/ppp0/pppoptions connect '/usr/sbin/chat -t 15 -f /etc/net/ifaces/ppp0/pppconnect' disconnect '/usr/sbin/chat -t 15 -f /etc/net/ifaces/ppp0/pppdisconnect')

Вначале pppd стартует, а потом сразу же останавливается.

Есть интересная особенность: игнорируется даже простая задержка сразу после вызова. Например, при таком вызове:

# $(/usr/sbin/pppd file /etc/net/ifaces/ppp0/pppoptions connect '/usr/sbin/chat -t 15 -f /etc/net/ifaces/ppp0/pppconnect' disconnect '/usr/sbin/chat -t 15 -f /etc/net/ifaces/ppp0/pppdisconnect'; sleep 10)

pppd будет остановлен сразу же после входа, не дожидаясь окончания задержки.

Естественно, что если в сценарии стоит вызов pppd через exec, то все работает хорошо. Но этот путь неприемлем при настройке etcnet.

Даже не знаю, стоит ли шаманить с audit? Ведь суть проблемы и так очевидна.

В порядке бреда: а не связано ли это с новыми bash-ем, где исправили всякие CVE, но, возможно, что-то привнесли с собой?

Created attachment 6169 [details]
Промежуточное решение в etcnet

Вот небольшая правка скрипта /etc/net/scripts/create-ppp, которая позволяет обойти эту проблему.

Решение не очень надежное, так как предполагается, что для запуска pppd потребуется не больше 5 секунд, при этом пользователь не настраивает updetach в pppoptions.

(В ответ на комментарий №11)
> В порядке бреда: а не связано ли это с новыми bash-ем, где исправили всякие
> CVE, но, возможно, что-то привнесли с собой?

Очевидно! Запуск

# ash ./test.sh

Проходит удачно!

Позже попробую подшаманить правильный вызов ifup через (d)ash, но думаю, что решать проблему, похоже, придется таки в bash. Посему опять перевешиваю пакет.

# rpm -q bash
bash-3.2.54-alt1

(In reply to comment #13)
> Очевидно! Запуск
> # ash ./test.sh
> Проходит удачно!
> Позже попробую подшаманить правильный вызов ifup через (d)ash, но думаю, что
> решать проблему, похоже, придется таки в bash. Посему опять перевешиваю пакет.
Возможно, это все-таки и не bash виноват, просто в нем усилили контроль за чем-то, а ppp не по стандарту делает что-то, вот его и посылает bash. 
Тут надо вызывать тяжелую артиллерию в лице ldv@ или vsu@.

Можно попробовать пооткатываться на более старые версии bash чтобы точнее выяснить момент поломки.

Плюс, странно тогда что у меня нигде на PPPTYPE=pptp не наблюдается.

Странно. p7+ ядерный pppoe работает нормально из etcnet
rpm -qa | grep bash
bash-builtin-lockf-0.3.1-alt1.qa1
bash-3.2.54-alt0.M70P.1

Единственное что -у меня pppoe в ядерном пространстве (http://lists.altlinux.org/pipermail/sysadmins/2013-June/036152.html)

(В ответ на комментарий №16)
> Можно попробовать пооткатываться на более старые версии bash чтобы точнее
> выяснить момент поломки.

А как это корректно сделать в рамках Сизифа?

Насколько я понимаю, посмотреть rpm -q --changelog bash на предмет дат обновлений и потом подключая по очереди срезы Сизифа за определённую дату (см. http://www.altlinux.org/Archive) пытаться откатывать пакет на более старую версию (apt-get install bash=x.y.z-rel).

Обнаружил еще один странный момент. Если выбросить из /etc/net/ifaces/ppp0/pppoptions установку updetach/nodetach, а также не указать эту опцию в командной строке:

# $(/usr/sbin/pppd file /etc/net/ifaces/ppp0/pppoptions connect '/usr/sbin/chat
-t 15 -f /etc/net/ifaces/ppp0/pppconnect' disconnect '/usr/sbin/chat -t 15 -f
/etc/net/ifaces/ppp0/pppdisconnect')

То запуск pppd проходит успешно. То же самое, если запустить pppd таким же образом из сценария. Однако, если в /etc/net/scripts/create-ppp также убрать опцию updetach из задания BASIC_PPPOPTIONS, то, хоть pppd и запускается успешно, но делает он это слишком быстро, поэтому дальше возникает ошибка `Cannot find device ppp0' при попытке настроить QoS. В результате оказывается, что pppd запущен, но QoS не настроено. Приходится добавлять `sleep 5' при таком запуске pppd из /etc/net/scripts/create-ppp.

Однако, если добавить опцию updetach в вызов, например, так:

# $(/usr/sbin/pppd updetach file /etc/net/ifaces/ppp0/pppoptions connect '/usr/sbin/chat
-t 15 -f /etc/net/ifaces/ppp0/pppconnect' disconnect '/usr/sbin/chat -t 15 -f
/etc/net/ifaces/ppp0/pppdisconnect')

то проблема стабильно остается. Очень похоже, что даже если пробема и не в pppd, то где-то на стыке bash и pppd. Потому что непонятно, как может отличаться поведение pppd в одной и той же версии bash, если использовать опцию по умолчанию без ее явного указания и с явным указанием той же опции?

Ситуация полностью повторяется при работе в bash4.

Кстати, pptp я не использую --- у меня только простейший dialup.

(В ответ на комментарий №20)
> Насколько я понимаю, посмотреть rpm -q --changelog bash на предмет дат
> обновлений и потом подключая по очереди срезы Сизифа за определённую дату (см.
> http://www.altlinux.org/Archive) пытаться откатывать пакет на более старую
> версию (apt-get install bash=x.y.z-rel).

Самый ранний архив Сизифа, который я смог найти --- от 11 июля 2012 года. Там bash и ppp почти тех же самых версий:

# rpm -q bash sh ppp
bash-3.2.51-alt1
sh-3.2.51-alt1
ppp-2.4.5-alt10

Проблема устойчиво повторяется при тех же условиях. Судя по журналу, правки в bash, которые могли вызвать эту ситуацию датируются исключительно этим годом. Пакеты в P7, где проблема была обнаружена в самом начале, датированы еще ноябрем прошлого года. По журналу изменение это еще задолго до всех правок, связанных с CVE.

В общем, похоже, глюк очень серьезный. У себя я использую обходное решение, которое опубликую здесь чуть позже. На дальнейшее копание в проблеме уже просто не осталось сил.

Не думаю, что за 2.5 года никто не пользовался ppp в ALT-е , даже у нас он используется.
Проверяйте на чистой установке, проверяйте свой bash и систему, может вообще вам трояна кто-то засадил.

Created attachment 6172 [details]
Еще одно промежуточное решение

Это решение мне нравится больше, так как делает меньше изменений. По сути оно просто убирает предустановленную опцию updetach и добавляет 5-секундную задержку после запуска pppd. Последнее нужно только лишь потому, что pppd без явно заданного updetach/nodetach отпускает консоль слишком быстро, и последующие действия в сценарии не успевают найти поднятый интерфейс ppp0.

(In reply to comment #24)
> Created an attachment (id=6172) [details]
> Еще одно промежуточное решение
> 
> Это решение мне нравится больше, так как делает меньше изменений. По сути оно
> просто убирает предустановленную опцию updetach и добавляет 5-секундную
> задержку после запуска pppd. Последнее нужно только лишь потому, что pppd без
> явно заданного updetach/nodetach отпускает консоль слишком быстро, и
> последующие действия в сценарии не успевают найти поднятый интерфейс ppp0.

Мне кажется, sleep-ы это не самое верное решение. На вашей машине sleep 5 хватает, а на какой-то и sleep 20 не хватит. Нужно искать корень проблемы и от него избавляться/чинить.

Проверьте в виртуалке, поставьте минимальный сизиф в неё, например.

(В ответ на комментарий №23)
> Не думаю, что за 2.5 года никто не пользовался ppp в ALT-е
Пытался этим летом или прошлым, не помню точно.

> Проверяйте на чистой установке, проверяйте свой bash и систему,
> может вообще вам трояна кто-то засадил.
У меня-то тоже сломалось.

хм. а как же он оу меня на pppoe работает на p7

noipdefault
noauth
default-asyncmap
defaultroute
hide-password
mtu 1492
mru 1492
noaccomp
noccp
nobsdcomp
nodeflate
nopcomp
novj
novjccomp
user stalker
password *****
lcp-echo-interval 20
lcp-echo-failure 3

(В ответ на комментарий №25)

> Проверьте в виртуалке, поставьте минимальный сизиф в неё, например.

Увы, не на моей машинке с 512М оперативы, 10Гб дискового пространства и простым целероном.

(В ответ на комментарий №23)
> Не думаю, что за 2.5 года никто не пользовался ppp в ALT-е , даже у нас он
> используется.
> Проверяйте на чистой установке, проверяйте свой bash и систему, может вообще
> вам трояна кто-то засадил.

Да в том-то и дело, что система чистая, как стекло. Только сегодня в результате
игры с Сизифом пришлось переустановить ее с нуля. Эффект стабильный. Пока что
пользуюсь предложенным промежуточным решением, хотя и сам знаю, что sleep --- это очень ненадежно. Немного резюмирую результаты.

1. Похоже, проблема не зависит от свежих правок. Откат на самые старые версии
вплоть до апреля 2012 года ничего не дает --- проблема остается.

2. Может быть, что проблема проявляется только при PPPTYPE=dialup, так как ни
pptp ни pppoe я не использую.

2. Проблема как-то связана с оболочкой bash. А именно, возникает она только при
запуске pppd из сценария или из командной строки в новом окружении, например,
так:

# $(/usr/sbin/pppd ...)

При вызове той же самой команды или сценария из ash (dash) проблема не
возникает. С csh/tcsh/zsh/... из того же зоопарка я не проверял, похоже, тема
для отдельного исследования.

3. Подозреваю, что проблема все же в pppd. Об этом говорит различное выполнение
команд

# $(/usr/sbin/pppd ...)

и

# $(/usr/sbin/pppd updetach ...)

Во втором случае проблема возникает, в первом --- нет, pppd запускается и
держит связь. Однако в этом случае pppd отпускает консоль еще _до того_, как
поднят интерфейс ppp0. В командной строке это некритично, но команды в сценарии
(например, настройки сети ifup-common), следующие сразу за запуском pppd все
еще не видят интерфейс ppp0. В промежуточном решении пришлось вставить 'sleep
5', чтобы интерфейс успел подняться до выполнения следующих действий.

4. На основании п.3 возникло подозрение, что проблема как-то связана с гонками
при запуске pppd только на относительно медленных машинках типа моей:

# cat /proc/cpuinfo 
model name      : Intel(R) Celeron(R) CPU 1.70GHz
stepping        : 3
microcode       : 0x4
cpu MHz         : 1700.084
cache size      : 128 KB
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pebs bts
bogomips        : 3400.16

Думаю, именно по этой причине проблема не воспроизводится на других, более
быстрых машинах. Увы, проверить сейчас этого не могу, так как других машин под
рукой нет.

Только что проверил --- проблема устойчиво воспроизводится в bash, dash (ash), zsh и tcsh. Так что, похоже, от типа оболочки ничего не зависит. Почему у меня раньше работало в ash, уже не скажу --- с тех пор прошла переустановка системы.

Посмотрел сейчас еще раз внимательно запуск pppd под autrace и обнаружил одну неприятную деталь, которую не заметил раньше. При вызове типа

# autrace /usr/sbin/pppd ...

проблема опять возникает --- pppd сразу же после запуска разрывает соединение. Именно поэтому выложенные мной раньше журналы autrace и оказались похожими. Пока что думаю, как еще можно обмануть pppd, чтобы он нормально отработал под autrace.

Ключевой момент здесь:

----
type=SYSCALL msg=audit(09.11.14 19:31:22.410:4056) : arch=i386 syscall=rt_sigaction success=yes exit=0 a0=SIGHUP a1=0xbf8496e4 a2=0x0 a3=0x8 items=0 ppid=17585 pid=17587 auid=maverik uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=1 comm=pppd exe=/usr/sbin/pppd key=(null)
----

Это единственнай вызов SIGHUP во всей трассе. Но как понять, кто инициировал этот вызов?

Проверено для шебанга ash, dash, tcsh, sh, bash, zsh, sash. Везде одинаковое поведение:
-- при наличии updetach в опциях после установления соединения тут же оно обрывается.
-- если указать вместо updetach -- nodetach, то работает, но не отсоединяется от родительского скрипта и блокирует его выполнение, если не загонять в фон.
-- если не указывать ни ту опцию, ни другую, то: в терминале (zsh и sh) сразу завершается с кодом 0 (но в фоне пытается соединиться, если получается, работает на pts c PPID=1); в скрипте работает оптимально ( передает дальше управление по завершению выполнения (а не сразу), устанавливает соединение, не завершает его, отсоединяется от скрипта и переходит на pts c PPID=1 ).

Возможно, ноги растут от баги #29832, там pppd в момент, где здесь он ловит SIGHUP, получал segfault ядра. Так что дело может быть даже не в шелле, а в ядре (заголовках/модулях/etc). Но та машина, где была та бага, эту не воспроизводит. А на этом ноутбуке не было той баги.

/proc/cpuinfo (первая половина, про 1 ядро из 2-х)
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 20
model           : 2
model name      : AMD E-450 APU with Radeon(tm) HD Graphics
stepping        : 0
microcode       : 0x5000119
cpu MHz         : 1650.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 6
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc nonstop_tsc extd_apicid aperfmperf pni monitor ssse3 cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs skinit wdt arat hw_pstate npt lbrv svm_lock nrip_save pausefilter
bogomips        : 3292.99
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

cpufreq стоит на "performance" для обоих ядер.

Обнаружилась еще одна особенность. Если добавить в pppoptions ключи persist и 'holdoff 5', то сначала pppd соединяется и тут же разъединяется, как и было описано раньше. Однако через 5 секунд (время задано в holdoff) pppd сам пытается соединиться повторно, и на сей раз все получается успешно.

Вот и мы её словили на openl2tp.

а pppd под strace никто не догадался запустить ?
мы свою проблему решили - это в openl2tp сокет лежал в "нестандартном" для ppp пути в /var/run/
теперь не падает.