configsync not working

Same here. :-(

 

 

After upgrading from 9.3.0 to 9.4.6 the config sync via iControl doesn't work anymore.

 

With a normal browser it works. On 9.3.0 it works too. But not on 9.4.6.

 

 

I call my script and it stalles until I get an 500-Error:

 

500 Internal Server Error at ./f5query.pl line 2667

 

 

Line 2667:

 

---

 

$do=$soap->synchronize_configuration(SOAP::Data->name('sync_flag' => 'CONFIGSYNC_ALL'));

 

---

 

timeout is set to 600

 

 

Here are some logs.

 

/var/log/httpd/httpd_errors:

 

Oct 13 11:37:38 bigip httpd[30238]: [error] [client 192.168.100.101] FastCGI: comm with server "/usr/local/www/iControl/iControlPortal.cgi" aborted: idle timeout (300 sec)

 

Oct 13 11:37:38 bigip httpd[30238]: [error] [client 192.168.100.101] FastCGI: incomplete headers (0 bytes) received from server "/usr/local/www/iControl/iControlPortal.cgi"

 

 

/var/log/ltm:

 

Oct 13 11:37:46 bigip bigpipe[9445]: 01110001:3: Error running config sync all

 

 

 

Can anyone give me a hint what went wrong?

 

 

 

Greetings

 

bsdpruegelknabe

This is a known issue(CR116460), read the forum here for a workaround:

 

 

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=1&tpage=2&view=Topic&postid=1496

 

 

also refer to SOL10132, this issue has only been fixed in BIG-IP version 10.0.1

 

 

https://support.f5.com/kb/en-us/solutions/public/10000/100/sol10132.html

 

 

For earlier versions you can request an engineering hotfix from F5 Support (quoting CR116460)

*facepalm* ... "only been fixed in BIG-IP version 10.0.1" and "request an engineering hotfix from F5 Support (quoting CR116460)" ... no comment ... *shakes head* Why in hell did they broke it...

 

 

Anyway: thank you very much for your answer, samstep.

 

I think I just dont use this function anymore if its such a hassle. >:-(

 

 

 

Greetings

 

bsdpruegelknabe

thank you samstep , we already begin to plan an upgrade.

 

For people who would like not to upgrade you can try this. This is something i did to fix it and it worked for me:

 

 

I had to manually edit the conf file adjusting the number of iControlPortal.cgi processes.

 

 

Edit /etc/httpd/conf/httpd.conf altering this line:

 

 

FastCgiServer /usr/local/www/iControl/iControlPortal.cgi -processes 1 -socket iControlPortal -idle-timeout 300

 

 

to read as:

 

 

FastCgiServer /usr/local/www/iControl/iControlPortal.cgi -processes 2 -socket iControlPortal -idle-timeout 300

 

 

Save the file and restart Apache by issuing a "bigstart restart httpd".

 

 

Thanks Nico, but this isnt really an supported way to do this? :-)

 

 

Anyway, since I really need this function (48 boxes screaming to be administrated by iControl) I think I will edit the httpd.conf.

 

 

 

Greetings,

 

bsdpruegelknabe

No bsdprugelknabe, you could open a case with F5 Support as Sam suggested:

 

 

 

This is a known issue(CR116460), read the forum here for a workaround:

 

 

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=1&tpage=2&view=Topic&postid=1496

 

 

also refer to SOL10132, this issue has only been fixed in BIG-IP version 10.0.1

 

 

https://support.f5.com/kb/en-us/solutions/public/10000/100/sol10132.html

 

 

For earlier versions you can request an engineering hotfix from F5 Support (quoting CR116460)

 

 

 

 

The change to the httpd.conf isn't supported and could lead to issues that Joe described in this post:

 

 

 

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=1&tpage=2&view=topic&postid=149655902

 

 

As I just posted in another forum thread(Click here), modifying the core webserver configuration can have unwanted side effects and F5 does not endorse this change. Several components such as System locking and Partition settings are stored in-process. When you increase the number of processes, this breaks the functionality of the above features. Also, by adding another iControlPortal process, you are also effectively doubling the memory needed to run iControl.

 

 

 

 

Aaron