DownloadsAvailable: false (action id xxx)

Action stuck in pending download status for 10 min.
The log shows:

At 13:14:20 +0900 - 
   ActionLogMessage: (group:1464,action:1465) Action signature verified for Downloads
   DownloadsAvailable: checking for 'http://XX.XX.XX.XX:XX/bfmirror/downloads/1465/0'
At 13:14:21 +0900 - 
   DownloadsAvailable: false (action id 1465)

How can I prevent this?
I have tried the “File Pre-Cache Wizard” function, however it did not improve.

I have seen this and it is normal, well usually. The part of information that is missing here is understanding the route that the agent takes to talk to the BES server. If there are multiple relays between that client and the BES server, then the content has to be deployed to all the relays in the chain.

You mention that you used the “File Pre-cache Wizard”, but did you pre-cache it to all the relays in the chain?

Is it possible that the target client moved to a different relay?

Martin

1 Like

The only way to completely prevent this is to deploy the action ahead of its scheduled start time and use the action Execution option ‘Start client downloads before constraints are satisfied.’ The Pre-cache wizard will can improve the behavior for very large downloads, but it only puts the file itself into the relay cache. There is action-specific metadata that also has to be downloaded through the relay chain, that will only happen when a client requests the download for that action id.

This behavior is much more visible when you are testing or deploying to one system. For mass deployments, the first client(s) to ask for the download will eliminate the delay for all the rest. It would also be more prevalent if UDP is not making it to clients reliably because they will wait 10 mins to check for downloads unless notified by the relay. If this is the case, you can increase the download check frequency on the client using the setting _BESClient_Download_CheckAvailabilitySeconds . I’d recommend 300 or 120, but the minimum value is 60.

1 Like

After 10 minutes, does the download proceed? Does the download become available on the relay after a certain amount of time has passed?

This message in the client log simply means that the download has not made it to the client’s local relay yet (or is no longer available).

Some possibilities:

  • The download did not make it to any of the top level relays or the server either. Check the action for problems with the download being cached to the server. Check top level relays to see if the download made it to them. Check to see if all relays in chain up to server are operational.
  • The available bandwidth between the server/top level relays is very low and/or the file being downloaded is very large causing the download to take a long time.
  • Download throttling settings are in place on the client, relays, and/or server causing the download to be throttled to a lower rate. Check to see if you have download throttling settings in place, and if there are, what are they set to?
  • The download cache’s on the relays are set too low (1 GB default), this may not be set high enough for what you are doing and some of the relays may be experiencing high cache turnover where you download gets kicked out of the cache as being least recently used and must be re-downloaded a second or third time. Increase the cache level on the server to at least 20GB and relays to at least 5GB (if space permits).

2 posts were split to a new topic: Large downloads not completing to all clients

I know exactly what the cause of this is, I have experienced it:

The default _BESClient_Download_RetryMinutes setting used to be 1 minute, but it was changed to 10 minutes. I strongly recommend changing this setting to 1 minute on all clients. The client will try again after 1 minute, then if that fails, it will double the wait time and continue to double it until it runs out of retries.

The other replies to this post are good info, but I’m fairly confident this is your issue.

Here are some recommended settings: An example clientsettings.cfg to set the default BigFix client settings at install time. Only works with the Windows EXE installer or the OS X installer. For linux, see here: https://github.com/jgstew/tools/blob/master/bash/install_bigfix.sh · GitHub


@steve I don’t see _BESClient_Download_CheckAvailabilitySeconds documented here: Legacy Communities - IBM TechXchange Community

This is the fist I’ve heard of this setting.


Related:

3 Likes

Download_RetryMinutes still has a default of 1 min, and relates to retrying a download that is available, but fails for some reason like the temporary network outage. The CheckAvailability option is specific to how frequently a client will ask its relay whether a package can be downloaded yet. Normally, it would not need to be adjusted because clients will be notified via UDP once the download becomes available (after it is first requested by any client).

1 Like

I distinctly remember upgrading BigFix and suddenly having downloads take 10 minutes on some clients some of the time and changing this setting to 1 minute fixed it. Maybe there was something else going on in that particular version that this setting happened to fix as a secondary result.