Bug #22647
closedarvados-api-server postinst can fail because of gem conflicts
Description
In this part of source:build/rails-package-scripts/postinst.sh :
# As of April 2024/Bundler 2.4, `bundle install` tends not to install gems
# which are already installed system-wide, which causes bundle activation to
# fail later. Work around this by installing all gems manually.
find vendor/cache -maxdepth 1 -name '*.gem' -print0 \
| run_and_report "Installing bundle gems" xargs -0r \
gem install --conservative --ignore-dependencies \
--local --no-document --quiet \
--install-dir="$bundle_path/ruby/$ruby_minor_ver.0"
run_and_report "Running bundle install" "$BUNDLE" install --prefer-local --quiet
run_and_report "Verifying bundle is complete" "$BUNDLE" exec true
The initial gem install
can fail if there are conflicts between gems that are already installed (from previous versions of the package) and gems in the current bundle, as seen in deploy-to-tordo: #1681 :
api.tordo.playg: ERROR: Error installing vendor/cache/rackup-2.2.1.gem: api.tordo.playg: "rackup" from rackup conflicts with installed executable from rack
After this, a manual bundle install
fixed the situation. The postinst didn't get to that line because it aborted after gem install
failed.
So, proposed solution: ignore errors from gem install
. If bundle install
can get us the rest of the way there, then that's all we need and we can let the postinst continue from there. If it doesn't work out, the postinst will fail at bundle install
, and that's fine.
We happened to see this after upgrading to Rails 7.1 but there's nothing specific to Rails or Rack or Passenger about this bug. It could arise with any two gems. This is just the first instance we've happened to see.
Updated by Brett Smith 8 days ago
- Related to Feature #22608: Upgrade to Passenger 6.0.26 (requires Rails 7.1+) added
Updated by Brett Smith 8 days ago
22647-postinst-ignores-gem-install-errors @ 6f9124a5aa1763a85ec21460fc858e84eef22de3
- All agreed upon points are implemented / addressed.
- Yes
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- N/A
- Code is tested and passing, both automated and manual, what manual testing was done is described
- No tests because it's a pretty small change and none of our test infrastructure will test the new logic. The best test would be to get this merged, rolled into an rc package, and then try it on another Curii cluster.
- Documentation has been updated.
- N/A
- Behaves appropriately at the intended scale (describe intended scale).
- No change
- Considered backwards and forwards compatibility issues between client and server.
- No change
- Follows our coding standards and GUI style guidelines.
- N/A (shell)
Updated by Tom Clegg 8 days ago
This LGTM, thanks.
Only comment is: is it worth mentioning in echo "Preinstalling bundle gems..."
(or echo " done."
) that it's OK/expected to see conflict errors here, as long as the following bundle install
works? Maybe a link to this ticket. Otherwise, this could be a red herring when reading logs to figure out some other problem.
Updated by Brett Smith 7 days ago
- Status changed from In Progress to Resolved
Applied in changeset arvados|2ff6e8dc0fbaa554442962fda6b170ac33bb58a6.