CentOS, OE 10.2B.
I am setting up a new testing VM and am having a helluva time getting an appserver to start when a broker owner is specified.
If I specify no broker owner, the appserver will start just fine so I assume that it is a permission thing. Further evidence that it is a permission issue is the fact that no appserver logs are created in my working directory when a broker owner is specified. However, the permissions for the working directory are wide-open.
I have had this similar set-up working on an older machine for quite some time but cannot determine what is going wrong here.
Any advice would be greatly appreciated.
Jeff Ledbetter Product Architect | Roundtable Software
Okay. So do you delete the old logs from when the AppServer did start (I am guessing you have). Is there any messages in the admserv.log?
Yes, NullPointerException. I've encountered this in the past and it was a permission issue on the work directory but not this time apparently. :-\
ava/jre1.5.0_11/bin/java -classpath /dlc/10.2b/jre/i18n.jar:/usr/java/jre1.5.0_11/lib/tools.jar:/dlc/10.2b/java/progress.jar:/dlc/10.2b/java/ext/mgmt_client.jar -DInstall.Dir=/dlc/10.2b -Djava.security.policy=/dlc/10.2b/java/java.policy -DCanonicalName=local.localhost:ID=AppServer com.progress.ubroker.broker.ubroker -t AS -i rtbapp102b -r rmi://linuxtest01:10210/rtbapp102b -f /dlc/10.2b/properties/ubroker.properties
[2/26/14 3:31:56 PM]  [OpenEdge] * Exception executing jvmStart:
[2/26/14 3:31:56 PM]  [OpenEdge] * java.lang.NullPointerException
[2/26/14 3:31:56 PM]  [AdminServer] * UBRemoteObject.startSvcProcess() failure: Cannot start AppServer process: " + UBroker.AS.rtbapp102b - process hasn''t exited (8162)
Side ways thinking. Does the AppServer connect to a database and if it does, does it do it directly? If so, does the new user have rights to connect to the database? Having just written this, probably not the issue as I think that would shown in the logs.
How are you editing the AppServer and returning it to the way it was? (i.e. by hand or copying files in and out (i.e. Old and new or Explorer/Management)
What happens if you try this on a new AppServer with no other configuration?
Brand new appserver created via OE Explorer. It doesn't do anything other than start the agent. I was trying to keep it as simple as possible to help identify the problem. It is the only appserver in a fresh-bowl OE 10.2B (with the 08 patch) installation.
Might be time to log a call. Only other thing I am thinking is the username and password correct and is it a user on the system or some sort of network user? Maybe also check the permissions on the executables in the %DLC/bin directory.
this post as spam/abuse.
who is the user starting the adminserver ? root ? somebody else ?
Hi.The adminserver is starting as root.
Before I ask more questions and ask for more files, is there a way to access that machine of yours remotely ?
Hi. Remote access is not immediately available.
It does not have to be immediate, whenever you want your broker to start :)
What is the password encoding algorithm used on your CentOS ?
Start the broker w/o username and then
1) (while logged) as root: "asbman -q -i broker -user rtb"
-> works or gives an error ?
let the broker running
2) (log in as rtb): "asbman -q -i broker"
Lastly, what happens when you start the whole adminserver under 'rtb' user ?
I really appreciate the help. Thank you.
I am unsure. How do I find this out?
“1) (while logged) as root: "asbman -q -i broker -user rtb"
-> works or gives an error ?”
“Lastly, what happens when you start the whole adminserver under 'rtb' user ?”
User is not authorized to start Admin Server.
1) make sure the /etc/hosts file of your Linux VM looks similar to this
<CRLF aka enter>
I have seen authorization errors "thanks" to this.
2) the encryption is defined here: /etc/pam.d/system-auth (the columns with password)
3) edit $DLC/bin/proadsv, go to the end, edit the last line (exec ...) and add -Dtracesso=1 prior the -Djvmstart.debug... eg ... -Dtracesso=1 -Djvmstart.debug ...
Save the file, and do "proadsv -start -interactive true" when logged as 'rtb', it should dip out password check.
For the sake of completeness as there have been few "debug" emails between me and Jeff, following has resolved the problem:
In /etc/pam.d/system-auth we need to disable sha512 encryption
comment out this line:
#password sufficient pam_unix.so sha512 shadow nis nullok try_first_pass use_authtok
put this one instead
password sufficient pam_unix.so md5 shadow nis nullok try_first_pass use_authtok
save the file and recreate the password for the user appbroker is desired to start under (rtb in the case).