Назад | Перейти на главную страницу

Почему здесь не работает pppd over ssh? Почему я не могу убить pppd?

Я пытаюсь настроить простой туннель ppp через ssh. Он отлично работает на нескольких машинах. Но на одной машине pppd "зависает":

> pgrep pppd | xargs ps up
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      4178  0.0  0.1   3020  1088 pts/1    Ds+  05:28   0:00 /usr/sbin/pppd

Любая попытка убить его (даже sudo kill -9 4178) не имеет никакого эффекта, который я вижу. strace -p 4178 тоже виснет аналогично. Через некоторое время я начинаю получать сообщения в dmesg как показано ниже.

Так он запускается с другой машины:

ssh -t root@server /usr/sbin/pppd passive noauth

Когда я делаю это на одной из работающих машин, удаленный конец pppd выкидывает на консоль мусор / двоичные данные (как и ожидалось). Когда я делаю это с неудачным, я не получаю вывода от pppd, но в конечном итоге сеанс ssh истекает. Если вместо этого я подключу ssh к машине, а затем запустите /usr/sbin/pppd passive noauth на отдельном этапе я также получаю ожидаемый двоичный результат.

Теперь у меня есть пара вопросов:

(Я пытался найти что-то похожее, но ничего не нашел, извините, у меня больше нет потенциальных клиентов)

Любые идеи?

Проблемная машина работает в debian на "оборудовании" VMware (как и те, которые работают), и она проявляет проблему при клонировании и на debian lenny (исходном) и на сжатии (после обновления)

dmesg записи:

[ 1198.727248] INFO: task pppd:4178 blocked for more than 120 seconds.
[ 1198.727507] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1198.727904] pppd            D ece2dc9c     0  4178   4174 0x00000004
[ 1198.727908]  00000098 00000082 f2503520 ece2dc9c 0000b1e7 00000000 c148d1c0 c148d1c0
[ 1198.727913]  f2a06100 f6e071c0 00000000 ece2dc18 f5cd07e0 00000000 ece2d400 ece2dc9d
[ 1198.727918]  00c52300 ece2dcbc f67bfef8 ec98e480 f291cec0 00000000 c10cf5b0 c10dfd21
[ 1198.727923] Call Trace:
[ 1198.727926]  [<c10cf5b0>] ? nameidata_to_filp+0x37/0x41
[ 1198.727929]  [<c10dfd21>] ? dput+0x21/0xb7
[ 1198.727932]  [<c11cfecc>] ? tty_ldisc_ref_wait+0x5f/0x76
[ 1198.727935]  [<c104de7a>] ? wake_up_bit+0x5c/0x5c
[ 1198.727938]  [<c11cb91b>] ? tty_ioctl+0x85f/0x8ba
[ 1198.727941]  [<c10fec18>] ? do_lock_file_wait+0x3d/0xd9
[ 1198.727944]  [<c1162c97>] ? _copy_from_user+0x2b/0x102
[ 1198.727946]  [<c11cb0bc>] ? tty_check_change+0xb9/0xb9
[ 1198.727949]  [<c10dbeb7>] ? do_vfs_ioctl+0x485/0x4c7
[ 1198.727952]  [<c10db59a>] ? do_fcntl+0x24f/0x3a2
[ 1198.727954]  [<c10dbf3a>] ? sys_ioctl+0x41/0x58
[ 1198.727957]  [<c12c6a1f>] ? sysenter_do_call+0x12/0x28
[ 1318.457225] INFO: task sshd:4174 blocked for more than 120 seconds.
[ 1318.457500] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1318.457896] sshd            D f25024cc     0  4174   2393 0x00000000
[ 1318.457901]  00000098 00000086 f2a06940 f25024cc 0000b246 00000000 c148d1c0 c148d1c0
[ 1318.457906]  f2503520 f6e071c0 00000000 3f056585 0000000f ece2d4bc 3f056585 f2503520
[ 1318.457911]  ec98bb38 ec98bbdc 00000000 00000000 00000000 c12c09b5 f2503520 c10327cb
[ 1318.457916] Call Trace:
[ 1318.457926]  [<c12c09b5>] ? schedule_hrtimeout_range_clock+0x3c/0xd9
[ 1318.457931]  [<c10327cb>] ? try_to_wake_up+0x13f/0x13f
[ 1318.457935]  [<c11cfecc>] ? tty_ldisc_ref_wait+0x5f/0x76
[ 1318.457940]  [<c104de7a>] ? wake_up_bit+0x5c/0x5c
[ 1318.457943]  [<c11c9ad3>] ? tty_poll+0x32/0x5e
[ 1318.457947]  [<c10dd4d5>] ? do_select+0x2a1/0x42e
[ 1318.457950]  [<c10dcb83>] ? poll_freewait+0x69/0x69
[ 1318.457953]  [<c10dcc25>] ? __pollwait+0xa2/0xa2
[ 1318.457955]  [<c10dcc25>] ? __pollwait+0xa2/0xa2
[ 1318.457958]  [<c10dcc25>] ? __pollwait+0xa2/0xa2
[ 1318.457960]  [<c10dcc25>] ? __pollwait+0xa2/0xa2
[ 1318.457963]  [<c10dcc25>] ? __pollwait+0xa2/0xa2
[ 1318.457965]  [<c10dcc25>] ? __pollwait+0xa2/0xa2
[ 1318.457968]  [<c10dcc25>] ? __pollwait+0xa2/0xa2
[ 1318.457971]  [<c10429c2>] ? lock_timer_base+0x19/0x35
[ 1318.457974]  [<c1042eb5>] ? __mod_timer+0x10c/0x116
[ 1318.457977]  [<c1042f89>] ? mod_timer+0x69/0x6e
[ 1318.457981]  [<c121325d>] ? sk_reset_timer+0xc/0x16
[ 1318.457984]  [<c1252f57>] ? tcp_event_new_data_sent+0x66/0x6b
[ 1318.457987]  [<c1255b85>] ? tcp_write_xmit+0x7a7/0x86a
[ 1318.457990]  [<c121760d>] ? __alloc_skb+0x50/0xfd
[ 1318.457994]  [<c12c12bc>] ? _raw_spin_lock_bh+0x8/0x1e
[ 1318.457996]  [<c1212e98>] ? release_sock+0x10/0xc4
[ 1318.457999]  [<c124b543>] ? tcp_sendmsg+0x6dd/0x7b7
[ 1318.458003]  [<c1162c97>] ? _copy_from_user+0x2b/0x102
[ 1318.458006]  [<c10dd7a0>] ? core_sys_select+0x13e/0x1c3
[ 1318.458009]  [<c12102a3>] ? sock_aio_write+0xc0/0xd4
[ 1318.458012]  [<c10d0655>] ? do_sync_write+0xa0/0xe4
[ 1318.458016]  [<c10b141c>] ? handle_mm_fault+0x222/0x238
[ 1318.458019]  [<c10f6096>] ? fsnotify+0x1de/0x1f9
[ 1318.458022]  [<c10dd9e8>] ? sys_select+0x6e/0x8f
[ 1318.458024]  [<c10d105e>] ? sys_write+0x3c/0x63
[ 1318.458028]  [<c12c6a1f>] ? sysenter_do_call+0x12/0x28

С тех пор я вспомнил, что на этой машине работает новое настраиваемое ядро ​​на основе 2.6.39. Я собрал себя. Когда я вернулся к стандартному ядру Ubuntu, все заработало. Насколько я помню, никаких патчей к ядру не накладывал, просто взял debian unstable .config и взял оттуда.

Если кто-то еще столкнется с этим, я создал суть с двумя конфигурациями ядра [работающими, сломанными] для использования в будущем. Но пока я просто буду придерживаться стандартного ядра Ubuntu для pppd.

Однако, независимо от того, какие параметры конфигурации активны в ядре 2.6.39, процесс pppd, который нельзя убить, по-прежнему выглядит странным ...