0

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"
AKS
  • 16,482
  • 43
  • 166
  • 258
  • What happens if you try to run `wget` on the URL directly from the command prompt? – Dexirian Jan 28 '20 at 18:33
  • Actually that pointed out that the IP behind the alias was not the correct server. Our team was doing Blue/Green setup and changed artifactory (dev instance's) alias hostname pointing to the new artifactory instance (IP) and it seems this particular Jenkins slave node still kept the new IP even after they pointed the alias back to original Artifactory instance's IP/fqdn host. Restarting `nscd` service on the slave machines helped. – AKS Jan 28 '20 at 22:05

1 Answers1

0

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.

AKS
  • 16,482
  • 43
  • 166
  • 258