Stud dies during loadtest

[bumptech]

Stud dies during loadtest

[duja]

More tests completed.

Loadtested without shared session:
stud -n 4 -b 127.0.0.1 81 -f 0.0.0.0 443 --write-proxy /usr/share/ssl/certs/elite.callofduty.com.cert

and without --write-proxy (and HAProxy 1.4 instead of 1.5).
stud -n 4 -b 127.0.0.1 81 -f 0.0.0.0 443 /usr/share/ssl/certs/elite.callofduty.com.cert

Still getting up to 10k connections, running 10k for 1-2min (total time of test 5-6min incl ramp up).
After 1-2min the child dies.

{client} Connection closed (in data)
{client} Connection closed (in data)
{client} Connection closed (in data)
{client} Connection closed (in data)
{backend-connect}: Connection timed out
stud: ev.c:2651: ev_io_stop: Assertion `("libev: ev_io_stop called with illegal fd (must stay constant after start!)", w->fd >= 0 && w->fd < ((loop)->anfdmax))' failed.
{client} Connection closed (in data)
{client} Connection closed (in data)
{client} Connection closed (in data)
{core} A child (17726) died! This should not happen! Goodbye cruel world!

/E

[duja]

I found a solution of the issue. It seems like stud dies when the conntrack table have reached its maximum.

Got this from syslog just before stud crashes: "kernel: [8905415.659519] nf_conntrack: table full, dropping packet."

Solved it by disabling the conntrack on the system (Fedora):

iptables -t raw -A PREROUTING -j NOTRACK
iptables -t raw -A OUTPUT -j NOTRACK

Hope that helps if someone else would see this problem.

I'm keeping the issue open. Stud should probably keep running even if the conntrack table is full?

[Neopallium]

This could be caused by the bug that I fixed in this pull request: #40

[jamwt]

Closing, since pull request 40 (#40) has been merged. Also, pull request 26 (#26) adds some robustness that a child will be re-spawned if it dies.