на будущее может кому пригодится:
Цитата:
List: poptop-server
Subject: Re: [Poptop-server] First connection always fails
From: James Cameron <james.cameron () hp ! com>
Date: 2005-01-21 0:12:19
Message-ID: 20050121001219.GI26391 () hp ! com
[Download message RAW]
On Wed, Jan 19, 2005 at 02:28:24PM +0000, John Horne wrote:
> If I reboot our vpn server then for some reason the first connection
> always seems to fail. The error shown is:
> pppd[5283]: Failed to open /dev/pts/1: No such file or directory
This was first documented as TODO item 20040521-1, on version 1.2.0-b3
and has yet to be fixed. Prior versions have not been checked. In
addition to happening on the first connection, it also occurs if there
are no other current pppd processes and memory is purged (of buffers
that may contain pppd pages, perhaps) using "dd < /dev/zero > tmp"
before the next connection. It has been reported to happen on 2.6
kernels only.
It seems like a race condition. As if /dev/pts/1 is closed before pppd
gets to use it. This is not intentional; pptpd has code to keep
/dev/pts/1 open until pppd begins to use it.
The pty is created in pptpctrl.c:566, in the function startCall(). Then
the program forks (line 580). tty_fd is for the pppd to read and write
to. pty_fd is for the pptpctrl GRE gateway to read and write to.
The parent immediately closes the tty_fd, since it doesn't need it. The
parent normally doesn't get scheduled by the kernel until after the
child has had a chance to run.
The child immediately duplicates the tty_fd and closes both the original
tty_fd and the pty_fd. Then the child executes pppd. If the execution
of pppd is delayed (e.g. by having to do disk I/O to bring it into
memory) then the parent will get to execute, closing the tty_fd.
Adding a one second sleep to the parent before it closes tty_fd usually
stops the problem. Add "sleep(1);" before the "close(tty_fd);" on line
612. This hides the problem; it is a kludge.
It is as if the reference counting of the file descriptor isn't being
done in the same way it used to be. Or the dup2() is failing and we
aren't catching it.
Please try the attached patch. This adds error checking to the calls
to dup2() in case they are failing. Please cause the "Failed to open
/dev/pts/1: No such file or directory" problem again, and check to see
if the preceeding section of the pptpd syslog indicates any failure of
the dup2() calls.
After that, you might like to confirm whether the "one second sleep
before the parent closes the fd" works for you. But if it is necessary,
then there's a defect to be fixed. Somewhere. Even the kernel.
--
James Cameron http://quozl.netrek.org/
HP Open Source, Volunteer http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
Subject: Re: [Poptop-server] First connection always fails
From: James Cameron <james.cameron () hp ! com>
Date: 2005-01-21 0:12:19
Message-ID: 20050121001219.GI26391 () hp ! com
[Download message RAW]
On Wed, Jan 19, 2005 at 02:28:24PM +0000, John Horne wrote:
> If I reboot our vpn server then for some reason the first connection
> always seems to fail. The error shown is:
> pppd[5283]: Failed to open /dev/pts/1: No such file or directory
This was first documented as TODO item 20040521-1, on version 1.2.0-b3
and has yet to be fixed. Prior versions have not been checked. In
addition to happening on the first connection, it also occurs if there
are no other current pppd processes and memory is purged (of buffers
that may contain pppd pages, perhaps) using "dd < /dev/zero > tmp"
before the next connection. It has been reported to happen on 2.6
kernels only.
It seems like a race condition. As if /dev/pts/1 is closed before pppd
gets to use it. This is not intentional; pptpd has code to keep
/dev/pts/1 open until pppd begins to use it.
The pty is created in pptpctrl.c:566, in the function startCall(). Then
the program forks (line 580). tty_fd is for the pppd to read and write
to. pty_fd is for the pptpctrl GRE gateway to read and write to.
The parent immediately closes the tty_fd, since it doesn't need it. The
parent normally doesn't get scheduled by the kernel until after the
child has had a chance to run.
The child immediately duplicates the tty_fd and closes both the original
tty_fd and the pty_fd. Then the child executes pppd. If the execution
of pppd is delayed (e.g. by having to do disk I/O to bring it into
memory) then the parent will get to execute, closing the tty_fd.
Adding a one second sleep to the parent before it closes tty_fd usually
stops the problem. Add "sleep(1);" before the "close(tty_fd);" on line
612. This hides the problem; it is a kludge.
It is as if the reference counting of the file descriptor isn't being
done in the same way it used to be. Or the dup2() is failing and we
aren't catching it.
Please try the attached patch. This adds error checking to the calls
to dup2() in case they are failing. Please cause the "Failed to open
/dev/pts/1: No such file or directory" problem again, and check to see
if the preceeding section of the pptpd syslog indicates any failure of
the dup2() calls.
After that, you might like to confirm whether the "one second sleep
before the parent closes the fd" works for you. But if it is necessary,
then there's a defect to be fixed. Somewhere. Even the kernel.
--
James Cameron http://quozl.netrek.org/
HP Open Source, Volunteer http://opensource.hp.com/
PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
Код:
["pptpd-dup-check.patch" (text/plain)]
? 248123.mbox
? BUGS
? RELEASING.quozl
? TODO.quozl
? autom4te.cache
? autoscan.log
? build-stamp
? configure.scan
? cvs.diff
? debian-old
? debian.diff
? import.ps.bz2
? install-stamp
? memory-analysis.txt
? pptpd-1.2.0-b3.tar.gz.asc
? pptpd-1.2.0-b4.tar.gz.asc
? pptpd-1.2.0-b4.tar.gz.md5sum
? pptpd-1.2.1-1.i386.rpm
? pptpd-1.2.1-1.src.rpm
? pptpd-1.2.1.tar.gz.asc
? pptpd-1.2.2-0.i386.rpm
? pptpd-1.2.2-0.src.rpm
? pptpd-1.2.2.tar.gz.asc
? pptpdinit.patch
? stamp-h1
? tmp
? debian/files
? debian/postinst.debhelper
? debian/postrm.debhelper
? debian/prerm.debhelper
? debian/substvars
? debian/tmp
? tools/vpnwho.pl.2004-03-12
? tools/vpnwho.pl.2004-03-16
? tools/vpnwho.pl.2004-03-18
Index: pptpctrl.c
===================================================================
RCS file: /cvsroot/poptop/poptop/pptpctrl.c,v
retrieving revision 1.16
diff -u -r1.16 pptpctrl.c
--- pptpctrl.c 14 Jan 2005 02:58:10 -0000 1.16
+++ pptpctrl.c 21 Jan 2005 00:07:19 -0000
@@ -584,8 +584,16 @@
_exit(1);
case 0: /* child */
- dup2(tty_fd, 0);
- dup2(tty_fd, 1);
+ if (dup2(tty_fd, 0) == -1) {
+ syslog(LOG_ERR, "CTRL: child tty_fd dup2 to stdin, %s",
+ strerror(errno));
+ exit(1);
+ }
+ if (dup2(tty_fd, 1) == -1) {
+ syslog(LOG_ERR, "CTRL: child tty_fd dup2 to stdout, %s",
+ strerror(errno));
+ exit(1);
+ }
#if 0
/* This must never be used if !HAVE_SYSLOG since that logs to stderr.
* Trying just never using it to see if it causes anyone else problems.
-------------------------------------------------------
? 248123.mbox
? BUGS
? RELEASING.quozl
? TODO.quozl
? autom4te.cache
? autoscan.log
? build-stamp
? configure.scan
? cvs.diff
? debian-old
? debian.diff
? import.ps.bz2
? install-stamp
? memory-analysis.txt
? pptpd-1.2.0-b3.tar.gz.asc
? pptpd-1.2.0-b4.tar.gz.asc
? pptpd-1.2.0-b4.tar.gz.md5sum
? pptpd-1.2.1-1.i386.rpm
? pptpd-1.2.1-1.src.rpm
? pptpd-1.2.1.tar.gz.asc
? pptpd-1.2.2-0.i386.rpm
? pptpd-1.2.2-0.src.rpm
? pptpd-1.2.2.tar.gz.asc
? pptpdinit.patch
? stamp-h1
? tmp
? debian/files
? debian/postinst.debhelper
? debian/postrm.debhelper
? debian/prerm.debhelper
? debian/substvars
? debian/tmp
? tools/vpnwho.pl.2004-03-12
? tools/vpnwho.pl.2004-03-16
? tools/vpnwho.pl.2004-03-18
Index: pptpctrl.c
===================================================================
RCS file: /cvsroot/poptop/poptop/pptpctrl.c,v
retrieving revision 1.16
diff -u -r1.16 pptpctrl.c
--- pptpctrl.c 14 Jan 2005 02:58:10 -0000 1.16
+++ pptpctrl.c 21 Jan 2005 00:07:19 -0000
@@ -584,8 +584,16 @@
_exit(1);
case 0: /* child */
- dup2(tty_fd, 0);
- dup2(tty_fd, 1);
+ if (dup2(tty_fd, 0) == -1) {
+ syslog(LOG_ERR, "CTRL: child tty_fd dup2 to stdin, %s",
+ strerror(errno));
+ exit(1);
+ }
+ if (dup2(tty_fd, 1) == -1) {
+ syslog(LOG_ERR, "CTRL: child tty_fd dup2 to stdout, %s",
+ strerror(errno));
+ exit(1);
+ }
#if 0
/* This must never be used if !HAVE_SYSLOG since that logs to stderr.
* Trying just never using it to see if it causes anyone else problems.
-------------------------------------------------------
оригинал: http://marc.info/?l=poptop-server&m=110626643809616&w=2
мне вроде помогло, пока не замечено рецидива
