Unable to uninstall SolMan 7.2 SR2 JAVA AAS Instance, on HANA DB

[ecosentino]

Hello, I installed the Solution Manager 7.2 Sr2 ABAP and JAVA stack as a standard product on a PAS, then installed an AAS with both the ABAP and JAVA instances on the one host.

I can see all processes are up and running, but when I shut down the AAS instance and then run SWPM 1.0 SP35 to run the Generic Uninstall product i get the following errors.

In the GUI I get this screen saying to check the configtool log in my sapinst_instdir, which when i check, there is no configtool.0.log file.

I then check the sapinst.log file and get this warning about the configtool that points to the config.properties file in the sapinst_instdir being unreachable with permission denied. But i see that sapinst is switching to the sapinst group before running configtool, and the sapinst_instdir is owned by sapinst group, so the file is accessible...

Your help is greatly appreciated. Am I using the wrong product choice to uninstall? I have sucessfully uninstalled many ABA instances with the Generic Uninstall product in SWPM.

[ecosentino · Accepted solution]

So i tried three scenarios for this uninstallation process to try and uninstall the AAS Java instance for SolMan 7.2 SR2:
Scenario 1:

I ran sapinst from the directory where i unpacked SWPM without setting env variables for temp, so the sapinst_instdir was placed in /tmp. During this method the process completed but did not in fact uninstall the instance. On the AAS i was unable to start the instance anymore, but from the PAS i could run GetSystemInstanceList sapcontrol function and i still saw the AAS DI as part of the system. Looking at sapinst/log it gave me the error:

ERROR 2022-12-14 12:54:15.023 (root/sapinst) id=syslib.process.currentProcessEnv.notUserSet errno=FSL-04016

Unable to change user. ID: 0. Operation not permitted

yet the sapinst GUI never gave an error, it ran to completion...


Scenario 2:

I ran the sapinst from teh same location, where i unpacked it, but this time i set the TMP and TEMP env variables to an different directory and the exact same issue appeared as in Scenario 1...

Scenario 3:

I created my own sapinst_instdir with 777 permissions and root:sapinst ownership, then moved into that directory then made an call to sapinst with the full path, that way the uninstall would run in my created sapinst_instdir. This is the scenario where i ran into the issue mentioned above in my original post. In my reply to Miguel i did state that after encountering this issue, if i did recursively set the permissions in my created sapinst_instdir to 777 and continued in the GUI it would resolve the problem, but i was looking for a workaround/fix to apply before starting the sapinst so i wouldn't have to perform parallel operations after running sapinst since I am trying to automate this.

After digging through the logs i saw that the issue arouse from permission issues with the config.properties file in the sapinst_instdir. Apparently sapinst was changing to <sid>adm:sapinst user/group to run the configtool, which was using the config.properties to startup. sapinst created the config.properties file with root:sapinst ownership and 640 permissions. Now, i am no expert, but i assume sapinst group permissions of read and root owner permissions of read and write should allow sapinst running as sapinst group and root user to read the file in question, as it is just a config file with some properties for configtool.

Nevertheless, it is not my job, nor desire, to fix SAP shortcomings. I found if i create an empty config.properties file with root:sapinst ownership and 777 permissions and then start sapinst the same manner in Scenario 3, then the uninstall proceeds without issues.Hope this helps someone in the future. I am unsure as to why the JAVA uninstall process is so flawed.

[VigneshPrabhu99]

Hello ecosentino

Please check below SAP Notes

2595196 - Release Note for *70JDS*.SAR of Software Provisioning Manager 1.0 - Covers No Longer Suppo...

2505142 - Release Note for *RMOS*.SAR of Software Provisioning Manager 1.0 - covers no longer suppor...

Let me know if this helps.

Regards,

Vignesh

[ecosentino]

Hello, I may be reading these wrong, but it seems like these refer to using SWOM 1.0 on outdated OS's. I am using SLES for SAP 15 SP1, so I should be good with using the SWPM 1.0 SP 35 SAR file to start SWPM instead of the RMOSSWPM*.SAR or RMOS70SWPM*.SAR.

[miguel_vizcaino]

Hi ecosentino ,

When I had those kind of errors, I used to change the mode of the whole /usr/sap/sapinst_instdir directory to 777 and try again, it worked for me when I saw these Java errors.

I don't know if I was setting the wrong owner or mode to the installation directories and files but this was my first action before troubleshooting these "permission denied" errors.

Try it and let me know if it works for you as well!

Miguel Vizcaino

[ecosentino]

Hello Miguel,

So i usually create the sapinst_instdir in /usr/sap directory, set the owner to root:sapinst and mode to 775, then i change into that /usr/sap/sapinst_instdir and start the SWPM with an explicit path call to the sapinst location so that sapinst is run from /usr/sap/sapinst_instdir without having to set environment variables for TMP.

While at the error screen in the GUI i was able to open another SSH to the app server and recursively change all items in the /usr/sap/sapinst_instdir to mode 777 and then continue with a retry in the GUI, and it worked.

My question is how can i ensure this does not happen when starting the sapinst, as the files in sapinst_instdir do not exist until the installation/uninstallation begins, and i do not want to have to react to the error by changing files permissions mid-process (I am trying to automate)