On 15-03-26 07:26 AM, Felipe Scarel wrote:
On Thu, Mar 26, 2015 at 12:37 AM, Yonas Yanfa <yo...@fizk.net> wrote:
On 15-03-24 03:26 AM, Claudio Jeker wrote:
On Mon, Mar 23, 2015 at 11:54:41PM -0400, Yonas Yanfa wrote:
Hi,
I'm running relayd/OpenBSD 5.6-stable on a KVM virtual machine. relayd
always crashes within a few hours of restarting it, but works properly
before that.
I guess you are talking about reloading relayd (as in relayctl reload)...
Killing all relayd processes and then running relayd.
When relayd stops working, sometimes the relayd process is up but
`relayctl
show summary` says that /var/run/relayd.sock doesn't exist. Other times
none
of the relayd processes are running.
I hit similar issues and came up with the following diff against -current.
It may apply to 5.6 but did not test that at all. I'm not 100% sure about
the ca.c change since OpenSSL is a black box.
Thanks for the patches.
Before I try to apply the patches, I think the issue might be caused by
having too many CLOSE_WAIT connections. I seem to have 2,236 CLOSE_WAIT
connections:
$ netstat -n|grep CLOSE_WAIT|wc -l
2236
And relayd seems to have 501 active connections:
relay www, session 1806 (501 active), 0, xxx.xxx.xxx.xxx -> :0, hard timeout
How can I get relayd to close these connections?
Cheers,
Yonas
I can confirm this has also been observed on my end, using relayd as a
forward ssl-inspecting proxy on amd64 hardware. Runs without issue for
a few hours, next time I look all the (ca|hfe|pfe) processes are gone,
only relays and the parent process remains. Killing all of them and
restarting the daemon "solves" the problem.
From what I understand, relayd is suppose to send an ACK packet when
the connection is in the CLOSE_WAIT state. There must be a bug in relayd
that prevents this from happening.
If this happened, the connection would be in LAST_ACK instead of
CLOSE_WAIT. The connection could be also be closed if it receiving the
following ACK.
Yonas
