We are using pppd-2.4.4 (built from source, with debugging) to terminate multiple incoming GRE-like tunnels on a server (Ubuntu Linux 2.6.24-19-server). Occasionally (perhaps once in 1000 times) we get the following problem: - the parent process (the process that does the GRE marshalling) hangs on a write() to the pty master. This hang keeps the CPU at 100%. - at the same time, the child process (pppd) hangs in tty_disestablish_ppp trying to set the previous line discipline on the pty slave (sys-linux.c:560). If I attach to the parent process with gdb, display a backtrace, and detach, this appears to break the deadlock, and both of them exit cleanly like nothing was wrong. The same happens if I use "strace -p" on the parent process. So this looks like a race condition somewhere. My pppd options look like this: ms-dns 41.204.40.19 ms-dns 41.204.40.9 novj asyncmap 0 noauth local lock hide-password -ac -pc +pap mtu 1468 mru 1468 lcp-echo-interval 30 lcp-echo-failure 4 nopersist 115200 noccp nopcomp noaccomp 41.204.40.10:192.168.0.10 plugin radius.so plugin radattr.so map-to-ifname mo-timeout 30 We run each pppd specifying only the parameters which vary, like this: pppd linkname 001264385324757-1360-32708 avpair Calling-Station-Id=001264385324757 I'd be grateful for any help with this. I suspect that I'm doing something stupid, but I can't see why a write() should eat up CPU. It should either block or return with an error, right? One more question: is it really necessary to set the pty's previous discipline? Surely the kernel will set it to sane defaults anyway? (What happens if a user does "kill -9 pppd"? -- tty_disestablish_ppp will not be called). I guess that in the case of "real" tty drivers, it would be good to restore the line discipline, or odd things may happen. I ask this, because if this does turn out to be a race in kernel code, then it would be easy enough to work around it in pppd by not running tty_disestablish_ppp if a pty (and not a real tty) is in use. I've tried this workaround, and it seems to work, but I don't feel that it's the proper fix. Many thanks, Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
