|
From: James Y. <ji...@yo...> - 2005-01-22 08:00:38
|
On Fri, 21 Jan 2005, Claas Hilbrecht wrote: > --Am Freitag, 21. Januar 2005 02:22 -0700 James Yonan <ji...@yo...> > 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 jail. 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 chroot. 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. James |