Errand 'Push-usage-service' is failing when default stack is cflinuxfs3 for the ruby_buildpack
search cancel

Errand 'Push-usage-service' is failing when default stack is cflinuxfs3 for the ruby_buildpack

book

Article ID: 415795

calendar_today

Updated On:

Products

VMware Tanzu Application Service VMware Tanzu Platform - Cloud Foundry

Issue/Introduction

This problem occurs after upgrading Tanzu Platform for Cloud Foundry to the affected versions below. The push-usage-service-release errand fail with error such as - 

 

ERR with an unsupported version of glibc.  

ERR /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /home/vcap/deps/0/vendor_bundle/ruby/3.3.0/gems/nokogiri-1.18.9-x86_64-linux-gnu/lib/nokogiri/3.3/nokogiri.so) - /home/vcap/deps/0/vendor_bundle/ruby/3.3.0/gems/nokogiri-1.18.9-x86_64-linux-gnu/lib/nokogiri/3.3/nokogiri.so

 

The deployment will fail to start and go into 'failing' state.

Environment

Affected versions

  • 6.0.17 - 6.0.20
  • 10.2.0 - 10.2.3

This issue affects foundations where the default stack is cflinuxfs3 for the ruby_buildpack for the versions specified below. If the  ruby_buildpack is set to default to cflinuxfs4, this issue does not apply. The available stacks are set on the “Cloud Controller” pane of the Cloud Foundry Tile.

 

  •  

Cause

This problem is caused by the version of Nokogiri shipped with push-usage-service-release.

Resolution

This issue is resolved in TPCF 6.0.21 and 10.2.4

 

The issue can also be mitigated by setting the position of the ruby_buildpack with cflinuxfs4 to be higher than the position of the ruby_buildpack with cflinuxfs3



[] ~ % cf buildpacks | grep -w "ruby_buildpack"

13         ruby_buildpack                   cflinuxfs4

32         ruby_buildpack                   cflinuxfs3

 

The other resolution is to temporarily disable the usage service errand on the Cloud Foundry Tile. This will not push a new version of the usage service to the foundation. The existing usage service will continue to run.

Lastly, the Usage Service post-deploy errand can be disabled for every apply changes, but the operator must ensure the errand is disabled on each apply changes.