NodeManager native library could not be loaded

@Charith Epitawatta 

Thanks for the suggestion, node manager started.

Have some more queries on this:

1. After changing the parameter i have to reconfigure the application 2 times, to get it working.
2. And while performing fresh installation how can we change NativeVersionEnabled to false?
3. Aurena and B2B/B2E are working fine, but in IEE i am getting 404. 

Thanks and Regards

Shitanshu Sharan

Just an update on this thread, we had exactly the same issue on Saturday whilst conducting a simple Stopping / Starting of the nodemanger.

I can confirm nothing else has changed on the server or within the middleware (release deployment / reconfigure).

The solution was to set the value of NativeVersionEnabled to false - this IFS instances has been running for 5 years with a setting of ‘True’????

I raised a ticket with IFS asking why this has happened but reading between the lines, there is no clear reason as to why..

On a positive note, this is the solution.. 

We too gradually began to see this behavior in each of our environments, seemingly one at a time. The Oracle document ID 1301911.1 references this issue and offers several options to ‘disable’ “NativeMode” but offers no details as to what the setting does, nor why it would happen in a successfully running system (going on 7 years). However, unlike ​@shitanshu sharan, the first system where I tested this did not seem to require a reconfigure of mws. I wonder if anyone out there can offer rational as to whether or not a reconfigure should be run (before I make the change in PRODUCTION!). There has to be some logical explanation why weblogic could run from 2018 to the end of 2024 with “NativeModeEnabled=true” set the entire time and never produce a single example of this error until this past December! Please IFS, shed a little light on this subject! 

** UPDATE **

Tonight, I tried to make this change in my PRODUCTION environment, and it did not go well! Once the setting was saved and the system was shutdown, nodemanager was ‘happy’, but none of the other ‘servers’ would shutdown:

1/17/25 6:35:26 PM <ERROR  > Received error message from Node Manager Server: [Server kill command for WebLogic server 'MainServer1' failed due to: [Waited for the process to finish for 20,000 millis, without success. This is a known limitation with the java.lang.Process.destroy call when the managed process has child or sub process such as a start script calling java. Users should perform the preferred method of connecting to the AdminServer to issue a shutdown request to stop a server. Only when that fails should nmKill be used. When there are no other options to stop the process, the OS level process kill should be used.]. Please check Node Manager log and/or server 'MainServer1' log for detailed information.]. Please check Node Manager log for details.
1/17/25 6:35:46 PM <ERROR  > Received error message from Node Manager Server: [Server kill command for WebLogic server 'IntServer1' failed due to: [Waited for the process to finish for 20,000 millis, without success. This is a known limitation with the java.lang.Process.destroy call when the managed process has child or sub process such as a start script calling java. Users should perform the preferred method of connecting to the AdminServer to issue a shutdown request to stop a server. Only when that fails should nmKill be used. When there are no other options to stop the process, the OS level process kill should be used.]. Please check Node Manager log and/or server 'IntServer1' log for detailed information.]. Please check Node Manager log for details.
1/17/25 6:36:06 PM <ERROR  > Received error message from Node Manager Server: [Server kill command for WebLogic server 'AdminServer' failed due to: [Waited for the process to finish for 20,000 millis, without success. This is a known limitation with the java.lang.Process.destroy call when the managed process has child or sub process such as a start script calling java. Users should perform the preferred method of connecting to the AdminServer to issue a shutdown request to stop a server. Only when that fails should nmKill be used. When there are no other options to stop the process, the OS level process kill should be used.]. Please check Node Manager log and/or server 'AdminServer' log for detailed information.]. Please check Node Manager log for details.
 

I assume this might be corrected by the reconfigure that ​@shitanshu sharan was referring to, but I was unwilling to take that chance as the system would no longer startup and I thought it needed to be running to successfully run a reconfigure???

Can someone from IFS please comment here?

​@Charith Epitawatta 

​@shitanshu sharan 

​@JamesW72 

Since this post is somewhat old, I am wondering if any of you have additional information you can share. I have successfully made this settings change in DEV and TEST without errors, but when I tried it in PROD, the MainServer, IntServer and AdminServer all throw errors (see above) when a shutdown of mws is attempted. Any additional information would be greatly appreciated.

Regards,

Bob

Hi,

​@woprhowe , did you solve this problem?

We are having the same problem, couldn't the problem be with some Microsoft update?

Thanks

Juraj

Yes and No to a solution. As I updated in my last post, the setting change resolved the issue in DEV and TEST, but broke PROD in a different way. I have decided to live with it “as is” (since a reboot of the virtual machine for mws allows it to startup properly), unless someone else offers a clue as to what is truly causing this issue. and Yes, it certainly could be something that came through Windows update, but it seems odd that the first reference to this problem is over 1 year old and I did not see this crop up in our environments until recently. I keep up with all Windows updates as approved by our server team each month (which ALWAYs include a shutdown and restart of mws) and we did not see this issue until November of 2024, which would be 10 months after ​@shitanshu sharan created this post. I have not had the time to dig any deeper into this issue, but my thought was to start with a new virtual machine and rebuild IFS from the ground up for testing (there is too much activity in my current environments to perform this kind of testing without impacting others in our organization). Also, I am not willing to go through the process of raising an IFS “case” for this issue since we are moving to IFS Cloud soon. My hope was that ​@JamesW72 would come back to this post an update us on his case, but nothing to date.

Feel free to reach out to me directly (Private Message via Community) if you would like to discuss this in more detail!

Kind regards,

Bob

Hi All, I found out what caused the issue.. AV (anti virus) on the middleware server. The AV was scanning the middleware and locking the files on start up..

James

​@JamesW72 , care to share 1.) What AV solutions your are using?, 2.) Was the solution to disable the AV during any mws activities, or exclude the folder from all scans?, 3.) Did you end up leaving the “NativeVersionEnabled=true” (as it is by default), or change it as prescribed by ​@Charith Epitawatta ?

Thank you,

Bob 

Hi guys,

Thank you very much for your answers.

Indeed in our case it was caused by AntiVirus SentinelOne. We will investigate what specifically blocked MWS and I will post the result in this topic.

(changing the NativeVersionEnabled parameter did not affect the behavior of this problem)

Thank you 

Regards
Juraj

We are not seeing anything logged in our endpoint protection suite, but this is a good avenue for investigation, given that we received mixed results from the setting change (which never made sense to me in the first place). Thanks to everyone for the responses!

More to come,

Bob

UPDATE: 

As near as I can tell, my issue is not related to our endpoint protection system. I set my DEV environment back to “NativeModeEnabled=true”, verified that mws could not properly startup after a shutdown, disabled all components of our endpoint protection on both the database server and middleware server, rebooted the middleware server,  and the problem still remains. Furthermore, DEV is now behaving the same a PROD did last week (eg. set to “true”, nodemanager fails to startup after a shutdown of mws, set to “false”, the other servers  [Admin, Main and Int] fail to shutdown). It is the gift that keeps on giving!

Going to start working on a new server to see if I can determine what has broken!

Hi ​@woprhowe,

Sentinel also didn't show anything in the logs, I assume it was checking the files when starting IFS and thus locked them. (as James mentioned). 

We are still analyzing which part of Sentinel is blocking this. Previously, the server was running ESET antivirus and it didn't have the problem. That's why we've rolled back ESET for now and are analyzing Sentinel protections. 

Juraj