Bug 1265740 - (6.4.z) Provided init.d scripts do not allow to easily fire several instances on the same system
Summary: (6.4.z) Provided init.d scripts do not allow to easily fire several instances...
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Scripts and Commands
Version: 6.3.3
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Romain Pelisse
QA Contact: Marek Kopecky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-23 15:45 UTC by ckyriaki
Modified: 2019-08-19 12:48 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-19 12:48:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Proposed fix of the init.d script (4.64 KB, patch)
2015-09-23 16:09 UTC, ckyriaki
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBEAP-3444 0 Minor Verified (7.0.z) Use script name for file related to Wildfly to allow multiple instances easily 2020-02-04 11:56:19 UTC
Red Hat Issue Tracker WFLY-5645 0 Optional Resolved Use script name for file related to Wildfly to allow multiple instances easily 2020-02-04 11:56:19 UTC

Description ckyriaki 2015-09-23 15:45:24 UTC
Description of problem: 
 When creating multiple services (i.e. 2 domain controllers on the same host, we are unable to do so without modifying the init.d jboss-as-domain.sh script. Also the service script doesn't provide options on passing system properties in. 

How reproducible:
Every time

Steps to Reproduce:
1. Copy the domain directory in the JBOSS eap ZIP installation to a new directory called domain_2 on the same level
2. Copy the init.d script from jboss-as-domain to jboss-as-domain2
3. The server won't sstart up with the right configuration

Actual results:


Expected results:
To be able to point the service startup script through the configuration without having to modify the actual script instance. 

Additional info:
I'm attaching a generic implementation of the script that would allow above and a specific example of my jboss-as.conf file.

This is an example on how it could work
cat /etc/jbossas-domain-appck/jboss-as.conf 
# General configuration for the init.d scripts,
# not necessarily for JBoss AS itself.

# The username who should own the process.
#
JBOSS_USER="jboss"
JBOSS_GROUP="jboss"

# The amount of time to wait for startup
#
STARTUP_WAIT=160

# The amount of time to wait for shutdown
#
SHUTDOWN_WAIT=60

# Location to keep the console log
#
# JBOSS_CONSOLE_LOG=/var/log/jboss-as/console.log
JBOSS_DOMAIN_BASE_DIR="/opt/redhat/jboss/6.3p3/appck"

JBOSS_HOME="/opt/redhat/jboss/6.3p3/"
JBOSS_MANAGEMENT_ADDR="127.0.0.1"
JBOSS_MANAGEMENT_NATIVE_PORT=9999
JBOSS_MANAGEMENT_HTTP_PORT=9990
JBOSS_STARTUP_OPTIONS=" -bmanagement $JBOSS_MANAGEMENT_ADDR -Djboss.domain.base.dir=$JBOSS_DOMAIN_BASE_DIR -Djboss.management.native.port=$JBOSS_MANAGEMENT_NATIVE_PORT -Djboss.management.http.port=$JBOSS_MANAGEMENT_HTTP_PORT"

Comment 1 ckyriaki 2015-09-23 16:09:18 UTC
Created attachment 1076262 [details]
Proposed fix of the init.d script

Comment 2 Romain Pelisse 2015-11-06 13:32:27 UTC
Hi Christina,

As discussed over IRC, I've looked at your script, and while it's quite handy to have all the instance related files (pidfile, log) using the name of the script, I'm not sure this change is needed. I think the script offer to replace those value by simply overriding the associate variable.

So technically, you can simply create a file /etc/init.d/jboss-1 which override the appropriate variables and then call the provided init scripts.

Now with your approach, you don't need to have all those overrides, which can be quite nice. I therefore I've created an issue on Wildfly - let's see other people feels about this proposals. If it's get merged, we'll see about backporting it to EAP.

Comment 10 Mike McCune 2016-03-28 23:30:47 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 11 JBoss JIRA Server 2016-04-04 13:45:49 UTC
Romain Pelisse <belaran> updated the status of jira JBEAP-3444 to Coding In Progress

Comment 12 JBoss JIRA Server 2016-06-09 13:36:40 UTC
Marek Kopecký <mkopecky> updated the status of jira JBEAP-3444 to Reopened

Comment 13 JBoss JIRA Server 2016-06-10 14:07:20 UTC
Marek Kopecký <mkopecky> updated the status of jira JBEAP-3444 to Resolved

Comment 14 JBoss JIRA Server 2016-08-23 11:38:50 UTC
Jiri Pallich <jpallich> updated the status of jira JBEAP-3444 to Closed


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