arcpy.DisconnectUser() run from WinServer to SDE on Linux w/ Oracle does not kill associated OS process

4893
3
Jump to solution
01-23-2015 03:44 PM
BlakeTerhune
MVP Regular Contributor

We have a database maintenance Python script (very similar to this one Esri recommends) and it kills all users with arcpy.DisconnectUser() before performing maintenance operations. This script is executed by Task Scheduler on Windows Server 2012 r2. Our ArcSDE 10.0 run on Oracle 11g on a Linux server. Here is an older, similar discussion‌ that ended in a suggestion to enable TCPKEEPALIVE.

What we've found is that when the script kills all users, all connections in the SDE.Process_Information table go away (as expected) but the associated database/os  process for each connection (gsrvr) remains. This is a problem because they build up and eventually hit the limit set in the Oracle initialization parameters. With further testing, we found that running the kill all users SDEMON command locally on the Linux server would kill the connections and clean up all associated gsrvr processes and sessions.

We are currently testing two possible solutions:

  1. Enable the TCPKEEPALIVE setting to hopefully find and kill the orphaned processes.
  2. Instead of using arcpy.DisconnectUser(), run the SDEMON command through Plink in Python using subprocess.Popen()

My questions are:

  1. Is this possibly a bug with SDE/Python?
  2. Is TCPKEEPALIVE a sensible option to solve this problem?
  3. With SDEMON depreciation, will the Python Plink command option be a good long-term solution?
0 Kudos
1 Solution

Accepted Solutions
BlakeTerhune
MVP Regular Contributor

We decided to enable the TCPKEEPALIVE option using the default KeepAlive ettings in Linux. We've continued using the same Python script with arcpy.DisconnectUser() and closely monitoring the sessions and processes in V$SESSION and V$PROCESS. It seems that TCPKEEPALIVE is reliably cleaning up the old processes (and sessions) after arcpy.DisconnectUser(). This will be our solution until our next ArcSDE upgrade.

View solution in original post

3 Replies
JoshuaBixby
MVP Esteemed Contributor

One could argue this is a bug, but even if it is a bug, there is a low probability it will be addressed.  The issue appears to be cleaning up the ArcSDE application server connections, and the ArcSDE application server no longer exists at ArcGIS 10.3.  Sure, ArcGIS 10.3 clients can connect to existing ArcSDE application servers (I think), but Esri won't put a high priority or much resources into addressing an issue with arcpy.DisconnectUser when the issue is dealing with retired functionality.

The SDE command line tools also don't exist at 10.3, but if older versions of them are working for you, I would say that seems like the best path forward.  Regarding Plink, why not just install the SDE command line tools on the machine the database maintenance script is running on.  That way, you wouldn't have to use Plink and remote into another machine.

Since the ArcSDE application server is dead, I would suggest you start considering changes to your architecture in the coming year or so.  In the meantime, goes with whatever works for you because getting potential bugs fixed for retired functionality is an uphill battle.

BlakeTerhune
MVP Regular Contributor

Thank you Joshua, I appreciate your reply. I'll try running SDEMON from the Windows Server like you suggested. We will continue testing and I'll post back if there are any significant developments.

0 Kudos
BlakeTerhune
MVP Regular Contributor

We decided to enable the TCPKEEPALIVE option using the default KeepAlive ettings in Linux. We've continued using the same Python script with arcpy.DisconnectUser() and closely monitoring the sessions and processes in V$SESSION and V$PROCESS. It seems that TCPKEEPALIVE is reliably cleaning up the old processes (and sessions) after arcpy.DisconnectUser(). This will be our solution until our next ArcSDE upgrade.