Bug 822476 - Embedded haproxy stops and then cannot restart when deploying to JBoss app
Summary: Embedded haproxy stops and then cannot restart when deploying to JBoss app
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OKD
Classification: Red Hat
Component: Containers
Version: 2.x
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Dan Mace
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-17 13:12 UTC by Dan Mace
Modified: 2015-05-14 22:54 UTC (History)
2 users (show)

Fixed In Version: > cartridge-haproxy-0.10.2-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-08 17:59:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 811671 1 None None None 2021-01-20 06:05:38 UTC

Description Dan Mace 2012-05-17 13:12:01 UTC
Description of problem:

Upon deploying code to a running scaled JBoss application, haproxy is restarted. However, haproxy fails to start after it has been stopped, leaving the front end of the application inaccessible.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Create a scalable JBoss application
2. Scale the application up to two nodes
3. Verify the default application is accessible from the front-end URL
4. Deploy a clustered WAR via git push
  
Actual results:

The deployment is successful, but the application is inaccessible from the public URL, and haproxy is no longer running.

Expected results:

A clean restart with haproxy alive and well.

Additional info:

Debugged this with Mike McGrath. It appears the stop script for haproxy is leaving a pid file on the filesystem which the start script refuses to overwrite, preventing startup. For example, using the stop script directly should produce the same bad state:

service libra stopuser cbaf254d39e7484b8eb71b90ba53f8fb

The problem may be isolated to:

/usr/libexec/stickshift/cartridges/embedded/haproxy-1.4/info/bin/app_ctl.sh

Comment 1 Ram Ranganathan 2012-05-17 21:19:20 UTC
Fixed with 5972dc780cd282949f591d28512ac804e86e6a20  -- issue was turning off selinux causes the system-wide haproxy daemon to show up in the list of processes for the user -- this fix makes that check more resilient.

Comment 2 Johnny Liu 2012-05-18 11:29:21 UTC
Verified this bug with devenv_1780, and PASS.

Reproduce steps:
1). Launch devenv_1780 instance, and replace app_ctl.sh with old one.
2). Create a scalable app.
3). setenforce 0
4). Use the following command to produce the bad state:
# service libra stopuser <haproxy_gear_uuid>
**NOTE**:
Actually this step is not necessary, due to the first thing of git push is to stop application.
5). Do git push to deploy new app. 
6). Now the application is inaccessible from the public URL.

Replace app_ctl.sh with new one, do git push again. Now the application is accessible from the public URL.


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