- CheckMates
- :
- Products
- :
- Developers
- :
- API / CLI Discussion
- :
- Re: Web API timeout
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Web API timeout
Hello,
We use Skybox with our Checkpoint environment but we face an issue in R80.20 in management server with a lot of Gateway.
Skybox try to use the Web API on a management server in R80.20 (HFA10 - API 1.3) with a script via the URL https://127.0.0.1/web_api/run-script.
The script is to catch the routing table of the Gateway the Management server administrate.
The problem occur if the task took more than 300 seconds, the client receive an error code "HTTP/1.1 502 Proxy Error" even if the task continue, I can see it if I'm connected to the console. There is no difference in the log file api.elg if the task is successful or unsuccessful
I already try some test
- With curl from skybox server
- With curl_cli directly on the management server
- to increase the session timeout during the login process but unsuccessfully
curl_cli -vvvv -H "Content-Type: application/json" -X POST -d '{"session-timeout":"1800","user":"XXXXXX","password":"YYYYYYYYY"}' https://127.0.0.1/web_api/login --insecure
Do someone know how to increase the timeout ?
Thanks
Bebertjack
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The timeout you are experiencing is not controllable via the API login parameters. The timeout, at 300 seconds you are running into is an apache default configuration. That if any POST command is received and data is not transferred over this connection for 300 seconds, apache will close this connection.
We do not recommend modifying this timeout as it effects several services. I would go the route phone boy is recommending, and try to understand why in the world a show route or similar command would take 5 minutes.
If you are querying hundreds of devices at a time, with run script targets. You might reduce to only a handful of devices at a time. As run-script will not pass any data over the API command until all scripts report there status.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Note the command sent must be executable in expert mode.
Regardless of how you're doing it, I can't think of a reason it should take more than 300 seconds (5 minutes) to return a result for the routing table.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I got similar problem. I want to install policy, but due to number of GWs connected to management and lack of resources of SMS it just takes up to 15 minutes. Currently upgrade of SMS for more powerful or, reducing number of GWs is not the way.
I'm getting timeout message after 10 mins, so I expect that it's because of default session-timeout: 600
I increased General session timeout in Gaia - but no affect to WEB_API timeout.
Is there any possibility to increase session time-out from 600 to 1200?
Thanks a lot for any advice
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also, are you trying to install policy to multiple gateways at once?
Try installing to fewer gateways.
Either that or try polling the task-id more frequently, which should also refresh the timer on the session.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Miroslav,
My name is Tamir Goren from Checkpoint RnD. I might be able to help you with better policy load performance time. I recently committed some performance enhancements in context of PMTR-62864 issue. You can open an SR with Checkpoint TAC and add this information. I will try to provide you with it.
Regards -Tamir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
On mgmt_cli you can increase the timeout by using '--conn-timeout'
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The timeout you are experiencing is not controllable via the API login parameters. The timeout, at 300 seconds you are running into is an apache default configuration. That if any POST command is received and data is not transferred over this connection for 300 seconds, apache will close this connection.
We do not recommend modifying this timeout as it effects several services. I would go the route phone boy is recommending, and try to understand why in the world a show route or similar command would take 5 minutes.
If you are querying hundreds of devices at a time, with run script targets. You might reduce to only a handful of devices at a time. As run-script will not pass any data over the API command until all scripts report there status.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the answer
I use the command below
curl_cli -v -H "Content-Type: application/json" -H "X-chkp-sid: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" -X POST -d '{"script":"netstat -rne","script-name":"Get routing rules","targets":["GW Target"]}' https://127.0.0.1/web_api/run-script --insecure
I think I find why we issue a timeout. Skybox put all the object tagged Firewall GW even the Cluster object itself in the GW target part of the command. The problem is that Cluster object do not respond to the request and then it took some time before CKPT put this task in error.
I confirm it with two tests:
- With all the target the task is complete in 18 mn en 14 sec
- With only the cluster member in the target part the task end in 4 mn 37 sec
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tanks for the answer
I use the command below
curl_cli -v -H "Content-Type: application/json" -H "X-chkp-sid: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" -X POST -d '{"script":"netstat -rne","script-name":"Get routing rules","targets":["GW Target"]}' https://127.0.0.1/web_api/run-script --insecure
I think I find why we issue a timeout. Skybox put all the object tagged Firewall GW even the Cluster object itself in the GW target part of the command. The problem is that Cluster object do not respond to the request and then it took some time before CKPT put this task in error.
I confirm it with two tests:
- With all the target the task is complete in 18 mn en 14 sec
- With only the cluster member in the target part the task end in 4 mn 37 sec
