berks install - Artifactory - Fetching cookbook index from ARTIFACTORY_URL/api/chef/some-chef-repo HANGS

Question

Artifactory version: Artifactory Professional 6.11.3 rev 61103900

Linux: Red Hat Enterprise Linux Server release 6.10 (Santiago)

berks install --debug just hangs at the following line (and spits no errors/warnings/etc):

Fetching cookbook index from http://my-company-artifactory-server-development:8181/artifactory/api/chef/chef-develop-virtual...

Full log showing some previous log lines are:

23:17:05 I, [2020-01-24T23:17:05.732159 #7235]  INFO -- : Checking if lockfile is trusted
23:17:05 D, [2020-01-24T23:17:05.732185 #7235] DEBUG -- : Checking my_wrapper_cookbook (>= 0.0.0)
23:17:05 D, [2020-01-24T23:17:05.732199 #7235] DEBUG -- :   Not in lockfile - cannot be trusted!
23:17:05 I, [2020-01-24T23:17:05.732212 #7235]  INFO -- : Installing from universe
23:17:05 D, [2020-01-24T23:17:05.732232 #7235] DEBUG -- :   Creating a resolver
23:17:05 Fetching cookbook index from http://my-company-artifactory-server-development:8181/artifactory/api/chef/chef-develop-virtual...

and this process step is just sitting here for last 2+ hours.

I couldn't find anything in Artifactory's log or berks install --debug which could point why this is happening and hanging!

My Berksfile:

# vim: ft=berksfile.ruby:

source "http://my-company-artifactory-server-development:8181/artifactory/api/chef/chef-develop-virtual"

cookbook "my_wrapper_cookbook", ">= 0.0.0"

Answer 1

Our team tried out a new Artifactory instance over the weekend and during the exercise, they pointed Artifactory host alias my-company-artifactory-server-development to this new IP (ex: 11.22.33.44).

• Whatever testing they did (by running various Jenkins pipelines), all went well with it.

Post testing (the new Artifactory instance), they switched back to original Artifactory instance (ex: 1.22.33.444) and brought new Artifactory instance down.

Seems like few of the Jenkins build/slave machines, still kept the new IP address (of newer Artifactory instance) for the same alias hostname.

i.e. running traceroute my-company-artifactory-server-development reported that it's pointing to new IP address and couldn't reach the IP maxing out all hops (as the new IP/machine was already down).

-or-

running wget http://my-company-artifactory-server-development:8181/artifactory/api/chef/chef-develop-virtual showed the same info about IP and didn't work (as expected) as Artifactory host alias was pointing to the new IP (which was down).

Restarting nscd service helped the host alias: my-company-artifactory-server-development point/re-pick up the correct (original) IP: 1.22.33.444 and now berks install is working as expected.