Я пытаюсь настроить простой туннель 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
на отдельном этапе я также получаю ожидаемый двоичный результат.
Теперь у меня есть пара вопросов:
ssh -t root@server /usr/sbin/pppd passive noauth
за один шаг и ssh root@server
и /usr/sbin/pppd passive noauth
в два шага?sudo kill -9
? Единственный известный мне способ - это перезагрузка.(Я пытался найти что-то похожее, но ничего не нашел, извините, у меня больше нет потенциальных клиентов)
Любые идеи?
Проблемная машина работает в 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, который нельзя убить, по-прежнему выглядит странным ...