Изначально я столкнулся с этой проблемой в P7, причем обновление до Сизифа не помогло: http://lists.altlinux.org/pipermail/sisyphus/2014-November/363127.html Чуть позже нашел описание аналогичной проблемы у другого человека в P7: http://lists.altlinux.org/pipermail/community/2014-November/682884.html Возможно, это как-то связано с поведением NetworkManager: https://bugzilla.altlinux.org/show_bug.cgi?id=28419 Не знаю, связано ли это с самим NM, etcnet или pppd. Я не силен в сетевой инфраструктуре ALTLinux. Так что, вешаю проблему туда, где ее обнаружил.
По логу в рассылке это похоже на локальную проблему. А именно, кто-то после поднятия туннеля шлёт 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/ теперь не падает.
