Bug 994223 - Broker can't write Gemfile.lock under systemd
Broker can't write Gemfile.lock under systemd
Product: OpenShift Origin
Classification: Red Hat
Component: Pod (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Krishna Raman
libra bugs
Depends On:
  Show dependency treegraph
Reported: 2013-08-06 15:29 EDT by Luke Meyer
Modified: 2015-05-14 22:20 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-02-26 14:07:11 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Luke Meyer 2013-08-06 15:29:10 EDT
Description of problem:
Using the F19 image on KVM, when the broker needs to re-create Gemfile.lock it is blocked:
Exception PhusionPassenger::UnknownError in PhusionPassenger::Rack::ApplicationSpawner (There was an error while trying to write to Gemfile.lock. It is likely that you need to allow write permissions for the file at path: 
/var/www/openshift/broker/Gemfile.lock (Bundler::InstallError)

The actual problem seems to be that httpd_unified is set to off.

Version-Release number of selected component (if applicable):
F19 Origin VM image release 2 running on KVM, out of the box

Steps to Reproduce:
1. rm /var/www/openshift/broker/Gemfile.lock
2. service openshift-broker restart
3. check /var/log/openshift/broker/httpd/error_log for errors, run rhc commands
4. getsebool httpd_unified

Actual results:
3. Errors mentioned in description
4. httpd_unified --> off

Expected results:
httpd_unified --> on
Broker restart should be able to create Gemfile.lock

Additional info:
Easy to fix -
# setsebool httpd_unified on
Comment 1 Krishna Raman 2013-08-21 14:05:06 EDT
The Gemfile.lock should be generated by puppet or manual installation.
Currently, it is not meant to be regenerated at runtime. 

When changing broker plugin, the Gemfile.lock needs to be generated manually after configuring the new plugin.

Do you see a case where it makes sense to generate the lock file during runtime?
Comment 2 Luke Meyer 2013-08-21 14:24:52 EDT
(In reply to Krishna Raman from comment #1)

> When changing broker plugin, the Gemfile.lock needs to be generated manually
> after configuring the new plugin.

It wouldn't need to be if it happened automatically, which is the mechanism we have been relying on in Enterprise installs to fix up install issues. Administrators do not and should not need to understand how rubygems and bundler work.

> Do you see a case where it makes sense to generate the lock file during
> runtime?

When yum update brings a new version of a gem.
When the administrator adds the admin console or changes any other broker plugin.
Comment 4 Luke Meyer 2013-09-26 10:07:08 EDT
BTW, the init.d openshift-broker service does automatically regenerate the Gemfile.lock:


For whatever reason, this didn't get transferred over to the systemd invocation. I'm not sure whether the httpd_unified boolean is consistently applied across the Origin deploy processes.
Comment 5 Jason DeTiberus 2013-10-30 12:27:37 EDT
Just tested this on a fully patched f19 system with the changes in this PR: https://github.com/openshift/origin-server/pull/4049 and generating the Gemfile.lock is working as it should.

getsebool httpd_unified returns the following:
httpd_unified --> on
Comment 6 zhaozhanqi 2014-01-03 04:16:02 EST
According to Comment 5 and I also check this issue on f19 system by oo-install, this issue has been fixed. 

1. rm -f Gemfile.lock
2. systemctl restart openshift-broker.service
3. Gemfile.lock will be regenerated
4. [root@dhcp-13-103 broker]# getsebool httpd_unified
httpd_unified --> on

Note You need to log in before you can comment on or make changes to this bug.