Python script executes in Desktop but not as published GP service

[JeffPuuri]

I have a python script that uses a module called ibm_db for accessing a DB2 database.  The script executes fine from ArcCatalog 10.1 and I can successfully publish it as a geoprocessing service.  However when I try to execute the actual service, the underlying python script fails with an error message coming from my import statement at the top of the code with ???import <list of modules> ImportError: no module named ibm_db???.  On this machine I have ArcGIS Desktop 10.1 as well as ArcGIS for Server 10.1.  I also have two python folders under C:\Python27, an ArcGIS10.1 and an ArcGISx6410.1.  I believe one is laid down with the Desktop install and the other when Server was installed.  The module that is failing has a 32 bit egg and a 64 bit egg that I installed in the Lib\site-packages under each respective python folder.  I actually had this working at one time in the past, but a server rebuild has precipitated the need to re-establish the environment and I have tried all manner of PYTHONPATH permutations in the environment variable as well as the registry to no avail.  I am pretty sure it is path related, or possibly permission related if the GP service is running as a user that may not have permission in the python folder, but what user would that be?  The arcgis system account?  Any ideas that anyone out there might have for me to try would be greatly appreciated.

Jeff Puuri
Applications Consultant
Roanoke, VA

[MichelleMestrovich1]

I'm having similar issues. Runs fine in desktop and I can publish but when running the actual service I get import errors on certain modules.  ESRI is helping but we haven't been able to resolve. Were you able to resolve your issue? thanks

[JeffPuuri]

Michelle - We had to use the following workaround to keep our project moving forward.  Like I mentioned, I had this solution working before this server rebuild occurred and looking back, I am suspicious of  SP1 for 10.1 not getting along with python. 

When I originally got this solution working it was straight 10.1 Desktop and Server before SP1 for each came out.  I configured my ibm_db third party python module for use with C:\python27 that esri lays down and everything was fine.  What I don't remember is if we subsequently installed the SP1 for Desktop and Server and it was still working.  I don't think we did.  It was working so we left it alone.

However when the server was rebuilt, 10.1 was installed along with SP1 before our app.  After going through the same config of my ibm_db python module, I ran into the errors noted above.

Fortunately, I had saved a copy of the entire C:\python27 folder structure from the working server (with no SP1).  On the rebuilt server, I just completely replaced C:\python27 folder that existed after 10.1 and SP1 were installed with the one I had saved from the working server and everything worked fine again.

This meant that we needed to preserve a copy of the C:\python27 folder structure for subsequent server deployments and make sure to include that folder replacement as one of our deployment steps after installing Server and Desktop.  Maybe we could have deployed servers without SP1 and it would have worked too, but we found this workaround that I mentioned and that was good enough to keep things moving forward.

I am no longer on that project and know that 10.2 is out now so it may not be an issue anymore.  Our experience seemed to come down to some specific interaction between 10.1, SP1, and python.

I hope this helps.

[MichelleMestrovich1]

Hi, Jeff,

Thanks for getting back to me. I found the issue was that for some reason the service was not looking for the 64 bit modules for reportlab. It was defaulting to the 32 bit ones. Not sure if this is a bug since I have both the 64 and 32 bit paths in the PythonPath. I moved a copy of the 64 bit python modules to the package directory on my server and then it worked. I have ESRI looking into it right now. At least for now it works for me although I don’t like the hack I had to do.

BTW, I’m on version 10.2.2 and completely patched as of 10/15/14.

[JeffPuuri]

Thanks for the update, Michelle; I am glad you were able to find a workaround.  Although our situations, Esri versions, and workarounds were different, I am detecting a similarity related to the executing program (gp svc, etc) not 'finding' the correct python module required for proper execution.  I appreciate your contribution to this thread as it confirms for me, and maybe for others who will read this in the future, that paths to python executables and modules should be considered when troubleshooting this type of execution issue, and that sometimes an unorthodox workaround (aka hack) as we have each described is necessary.  If you wind up with a final resolution that you have time to post back to this thread, I would love to read about it and file away for future reference as I am doing more and more with python-based gp services and will continue to do so in the future.  Have a great day!

Jeff Puuri

[MichelleMestrovich1]

One other thing I found which is a known bug and I’m hoping will be fixed in future versions. If you are using SDE connections with your GP Service, when you publish they are suppose to be automatically copied to the package workspace. Well they are not. This was very frustrating, but I finally figured it out and found some posts on it. You have to manually copy the connections to the package directory (…\extracted\v101\). If you overwrite the service you have to repeat the process. Just one more thing to remember until they fix it. Hope this helps others.

[JeffPuuri]

Thanks, Michelle, that also is helpful.  I had to do some hacking of my own down in the published service folder (c:\arcgisserver\directories\...).  For the very service that I was having issues with as described above, once I did get it to run so that I could publish it, the publishing placed a copy of the ibm_db python module in the actual published service folder, and having the module in that folder cause the gp service to crash when trying to execute.  Once I removed those modules from the published service folder, everything worked again.  It is good to know there are other situations that might cause the need for alterations down in that published service folder.