Highlighted
Contributor.
Contributor.
1779 views

GroupWise Messenger 18 installation segfaults


Hi!



I have two GW 18 systems.



On a small GW 18 test system (single gwadminservice) the installation works fine and the Messenger 18 system works just fine.

On a production GW 18 system (multiple POs, multiple gwadminservices on different ports, etc.) the installation just segfaults (yes, quite ugly) during 'Connecting to GroupWise' resulting in a non-functioning system.



I have tested a fresh installation and a migration with both Messenger 18.0.0 and the new 18.0.1 version. Same result, segfault during installation and the gwm-nmma agent does not come up.



Anyone seen this?



Georg
Labels (1)
0 Likes
4 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: GroupWise Messenger 18 installation segfaults

Georg,

> I have tested a fresh installation and a migration with both Messenger 18.0.0 and the new 18.0.1 version. Same result, segfault during installation and the gwm-nmma agent does not come up.
>
>
>
> Anyone seen this?


The segfaults we have seen were with 18.0.0 and fixed in 18.0.1. Since it is still happening for you,
please grab the core and a supportconfig. Zip those and upload them to ftp://ftp.novell.com/incoming.
Open an SR, name the zip file with the SR number, and we can get it reported to engineering.

Thanks,

Pam

0 Likes
Highlighted
Contributor.
Contributor.

Re: GroupWise Messenger 18 installation segfaults


Hi Pam!



I just did some debugging and i think i have found the root cause.



The configure.sh script wants to write some attributes to the arangodb and fails. (There are error messages about "Unable to write attribute" before the segfault)
By default on arangodb only ssl access is enabled and the "bin/defobjs" does obviously not work correctly over ssl. Please note that this is on SLES 12 SP3.



As a consequence no SSL or server attributes are available in the arangodb at the time the GroupwiseConnection is configured, most probably the root cause for the segfault.



For testing i have enabled non-ssl endpoints for arangodb and hacked the configure.sh script to make non-ssl connections to the arangodb.



Surprise, now the configure is successful (the attributes get written just fine over plain tcp) and reverting to ssl db-connections after the successful installation allows all services (mars, nmma and nmaa) to start.



I tested with a fresh install and with a migration and could get both variants up and running with my changes to only use unencrypted tcp connections during the configuration.
Please note that i had to switch to ssl for the final agent config. the tcp mode was only required for the configure.sh script.



Looks like there are some ssl issues with the defobjs binary (at least on SLES 12 SP3 - the server is old and has a long!!! update history)



I am now running on the new SLES 12 SP3 server with Groupwise Messenger 18.0.1. So no need for a core dump analysis, just take a look a look at the ssl part.



Thx,
Georg




>>> Pam Robello<pam.robello@microfocus.com> 26.03.2018 13:22 >>>



Georg,





> I have tested a fresh installation and a migration with both Messenger 18.0.0 and the new 18.0.1 version. Same result, segfault during installation and the gwm-nmma agent does not come up.



>



>



>



> Anyone seen this?





The segfaults we have seen were with 18.0.0 and fixed in 18.0.1. Since it is still happening for you,
please grab the core and a supportconfig. Zip those and upload them to ftp://ftp.novell.com/incoming.



Open an SR, name the zip file with the SR number, and we can get it reported to engineering.




Thanks,




Pam
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: GroupWise Messenger 18 installation segfaults

Georg,

> I am now running on the new SLES 12 SP3 server with Groupwise Messenger 18.0.1. So no need for a core dump analysis, just take a look a look at the ssl part.


The connection to the database from both the migrator and defobjs tools use SSL. We will not run unless
SSL is properly configured for arangodb. Could you tell us what is exactly segfaulting in the script
and what your summary page looks like.

Thanks,

Pam


0 Likes
Highlighted
Absent Member.
Absent Member.

Re: GroupWise Messenger 18 installation segfaults


Hi!




I already opened a SR #101154681141.




The segfault is a consequence of defobjs not being able to write to arangodb.

arangodb ssl is working fine. (arangosh to a ssl endpoint works without problems)

If the configure script tries to add/modify an attribute in arangodb (which it does by calling defobjs) over ssl (-t parameter) the db access fails.

If the exact same write is made with defobjs without ssl (no -t parameter) to a tcp endpoint the db access is fine.




If the configure is done over plain tcp everything is fine. After the configuration the agents are able to talk ssl to arangodb., it is just defobjs which has the problem.




As i have patched the configure.sh script to use tcp and got my system up and running i do not have a immediate problem, but there is something wrong with defobjs.




Georg



>>> Pam Robello<pam.robello@microfocus.com> 27.03.2018 17:22 >>>



Georg,




> I am now running on the new SLES 12 SP3 server with Groupwise Messenger 18.0.1. So no need for a core dump analysis, just take a look a look at the ssl part.





The connection to the database from both the migrator and defobjs tools use SSL. We will not run unless

SSL is properly configured for arangodb. Could you tell us what is exactly segfaulting in the script

and what your summary page looks like.




Thanks,




Pam
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.