|
Here is data from the backup which crashed, seems like it is probably a
race issue since both stacks seem to be operating upon the same data
(parameters are the same):
stack 1:
ip_vs_conn_unhash+0x7d(0xec589ea0, 0x0, 0x286, 0xebfad620, 0xf7e4d480)
ip_vs_check_template+0x32 (0xec589ea0, 0xae8644a6, 0x0, 0x8c55b4cd, 0x5000)
ip_vs_sched_persist+0x262 (0xf7966560, 0xf767b500, 0xc0295edd, 0x6,
0xae8644a6)
ip_vs_schedule+0x204 (0xf7966560, 0x767b500, 0x8c55b4cd, 0x5000, 0x5000)
...
---
stack 2:
__write_lock_failed+0x7 (0x6, 0xac8644a6, 0x0, 0xf74e2980, 0xec589ea0)
.text.lock.ip_vs_conn+0x5
ip_vs_conn_hash+0x7a (0xec589ea0, 0x0, 0xc0249d32, 0xebb7a960, 0xc1c1e800)
ip_vs_conn_hash+0x76 out %eax, $0x2a
ip_vs_conn_hash+0x78 add %al,(%eax)
ip_vs_conn_hash+0x7a mov 0xc043a460, %edx
ip_vs_check_template+0x4c (0xec589ea0, 0x0, 0xc0249d32, 0xebb7a960,
0xc1c1e800)
ip_vs_sched_persist+0x262 (0xf7966560, 0xf74e2980, 0xc0295edd, 0x6,
0xae8644a6)
...
-----
I'll keep the backup in kdb while I
1) upgrade to 2.4.25 to make sure I can reproduce it on that version
2) patch and see if I can reproduce.
Thanks
Brett
Brett E. wrote:
Thanks, I can reproduce it easily, in fact it just happened to the
backup test machine this morning. I reproduce it by redirecting 1000
connections/sec load from our production servers via a network tap to 2
LVS machines running keepalived in primary-backup mode so it's stressing
it quite a bit. I'll apply this then tell you how it goes.
|
