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

Re: [Openvpn-users] Problem with plugin openvpn-down-root.so and SIGUSR1 restarts

  • Subject: Re: [Openvpn-users] Problem with plugin openvpn-down-root.so and SIGUSR1 restarts
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Sat, 22 Jan 2005 01:00:45 -0700 (MST)

On Fri, 21 Jan 2005, Claas Hilbrecht wrote:

> --Am Freitag, 21. Januar 2005 02:22 -0700 James Yonan <jim@xxxxxxxxx> 
> schrieb:
> > Try this patch -- in my testing, it causes two SIGUSR1 signals spaced only
> Hmm, this makes it even worse. The first connect succeed but after that the 
> connection was never established again. I give you the full log even if 
> it's rather large.

I'm not clear what is failing here.  In the provided log file, it seems
that all the SIGUSR1s are handled correctly.

Remember, all this patch does is try to eliminate the possibility that two 
SIGUSR1s sent in rapid succession might trigger a hard SIGHUP reset.

The issue that you originally raised was that a SIGUSR1 was causing a hard 
reset that caused a fatal exit because OpenVPN was running in a chroot 

I was able to confirm that two SIGUSR1 signals spaced a few milliseconds 
apart would cause this behavior in 2.0-rc8.

All the patch does is fix this specific issue so that two SIGUSR1 signals
sent in this manner will cause a standard SIGUSR1 restart, not a hard
SIGHUP reset.  This is important because a SIGHUP reset will force program 
exit if the execution environment has been modified by user, group, or 

The patch works by temporarily disabling SIGUSR1 during the
initialization of the tunnel context state (if the context state
initialization is interrupted by a signal, OpenVPN has no choice but to
trigger a hard reset because the tunnel context itself is now in an
undefined state).

I also don't completely understand why your OpenVPN daemon is getting 
"rapid-fire" SIGUSR1 signals in this manner.


Openvpn-users mailing list