Server Version: Apache/2.2.4 (Unix) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.7l Server Built: Jun 1 2007 12:33:32 running on gentoo linux started apache with one balancer configured (balancer://u0). the balancer manager page shows the correct statistics: Load Balancer Manager for X Server Version: Apache/2.2.4 (Unix) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.7l Server Built: Jun 1 2007 12:33:32 LoadBalancer Status for balancer://u0 StickySession Timeout FailoverAttempts Method 0 4 byrequests Worker URL Route RouteRedir Factor Set Status Elected To From http://127.0.0.1:3000 1 0 Ok 1318 489K 123K http://127.0.0.1:3001 1 0 Ok 1311 482K 132K http://127.0.0.1:3002 1 0 Ok 1307 475K 168K http://127.0.0.1:3003 1 0 Ok 1306 487K 5.6M http://127.0.0.1:3004 1 0 Ok 1300 476K 81K Apache Server at X Port 80 add a config for a second balancer (balancer://k0). restart apache with 'apache2ctl graceful' which sends a USR1. reload the balancer manager page and the statistics are incorrect. notice that statistics for k0 are really from u0. new hits correctly update u0. Load Balancer Manager for X Server Version: Apache/2.2.4 (Unix) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.7l Server Built: Jun 1 2007 12:33:32 LoadBalancer Status for balancer://k0 StickySession Timeout FailoverAttempts Method 0 4 byrequests Worker URL Route RouteRedir Factor Set Status Elected To From http://127.0.0.1:3100 1 0 Ok 1318 489K 123K http://127.0.0.1:3101 1 0 Ok 1311 482K 132K http://127.0.0.1:3102 1 0 Ok 1307 475K 168K http://127.0.0.1:3103 1 0 Ok 1306 487K 5.6M http://127.0.0.1:3104 1 0 Ok 1300 476K 81K LoadBalancer Status for balancer://u0 StickySession Timeout FailoverAttempts Method 0 4 byrequests Worker URL Route RouteRedir Factor Set Status Elected To From http://127.0.0.1:3000 1 0 Ok 11 2.7K 3.5K http://127.0.0.1:3001 1 0 Ok 9 2.2K 369 http://127.0.0.1:3002 1 0 Ok 8 1.9K 328 http://127.0.0.1:3003 1 0 Ok 8 1.9K 328 http://127.0.0.1:3004 1 0 Ok 8 1.9K 328 Apache Server at X Port 80
This is caused by the way this data is saved in shared memory. The shared memory is not reset during a graceful restart. This is a really nasty issue since we cannot simply reset this shared memory during a gracful restart as it might still be used by other processes / threads that are dying gracefully. This needs some more thoughts to fix it.
*** Bug 41680 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 44736 ***