[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] OpenVPN eats all my CPU when using the mgmnt interface


  • Subject: Re: [Openvpn-users] OpenVPN eats all my CPU when using the mgmnt interface
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Wed, 5 Jan 2005 14:29:44 -0700 (MST)

On Wed, 5 Jan 2005, Mathias Sundman wrote:

> On Wed, 5 Jan 2005, Mathias Sundman wrote:
> 
> > I just observed that one of my OpenVPN processes were using 99% of my CPU on 
> > my newly installed password auth based firewall.
> >
> > After some testing I've found that it's the management interface that's 
> > causing it. Starting OpenVPN and everything is calm, but as soon as I connect 
> > to the management interface, OpenVPN starts looping eating up all CPU, and it 
> > does not stop after I disconnect from the management interface. I have to 
> > restart OpenVPN to get rid of the problem.
> >
> > Connecting with a OpenVPN client also causes openvpn to exit this loop.
> >
> > openvpn@fw-ktn:/etc/openvpn$ openvpn --version
> > OpenVPN 2.0_rc5 i686-pc-linux [SSL] [LZO] built on Dec 16 2004
> >
> > openvpn@fw-ktn:/etc/openvpn$ uname -a
> > Linux fw-ktn 2.4.26 #2 Wed Jun 30 15:30:57 CEST 2004 i686 unknown
> >
> > This is what I get when running strace on the process:
> >
> > poll([{fd=5, events=POLLIN|POLLPRI}, {fd=6, events=POLLIN|POLLPRI}, {fd=3, 
> > events=POLLIN|POLLPRI}, {fd=7, events=POLLIN|POLLPRI, revents=POLLNVAL}], 4, 
> > 10000) = 1
> > time(NULL)                              = 1104923675
> > poll([{fd=5, events=POLLIN|POLLPRI}, {fd=6, events=POLLIN|POLLPRI}, {fd=3, 
> > events=POLLIN|POLLPRI}, {fd=7, events=POLLIN|POLLPRI, revents=POLLNVAL}], 4, 
> > 10000) = 1
> 
> A little follow-up on this problem.
> 
> I had no problem reproducing it on an other machine, but I found another 
> interesting thing. The problem only occurs when running openvpn as a 
> tcp-server. If I use --proto udp the problem never occurs.

I've already found the bug.  It only occurs in tcp server mode, in event 
poll mode, and when the management interface is being used.  Event poll 
mode is used by all *nix OSes except for Linux 2.6, so the bug won't occur 
there.

The bug occurs because a subtle difference in behavior between poll and
epoll breaks the OpenVPN event abstraction layer which is supposed to
(from an API perspective) hide the differences between poll, epoll,
select, and WSAWaitForMultipleEvents. Basically epoll doesn't care if you
close a file descriptor in the event list -- it will do the sane thing and
remove it from the list automatically.  Poll on the other hand doesn't
like to see a closed fd in the event list, and will return immediately
with POLLNVAL.  So the fix is that the OpenVPN poll driver needs to 
emulate the epoll behavior -- or OpenVPN needs to make sure that it 
manually deletes all closed fds from any relevant event lists.

I should have a fix shortly.

James



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users