upgrade 10.5.1 arcgisoutput directories changed?

1767
14
Jump to solution
05-21-2018 01:57 PM
Ravichandran_M_Kaushika
Occasional Contributor

dear Readers,

good afternoon.  our production team migrated the ArcGIS server instance to 10.5.1.  

After the upgrade we observed c:\temp became the 'scratch' or working directory for all the services and GP Functions.  as a result of this change, c:\drive was getting filled up quickly and services/apps were throwing errors,

on the other hand, we verified that site and all services in load balanced clustered DEV instance to be set to:

cache: \\myShare_das\GeoData_FS\directories\arcgiscahe

jobs: \\myShare_das\GeoData_FS\directories\arcgisjobs

output: : \\myShare_das\GeoData_FS\directories\arcgisoutput

system: : \\myShare_das\GeoData_FS\directories\arcgissystem

cache (tiles): \\myCacheServer\arcgiscache

the values are consistent at the site and individual service level.

Since we don't have direct access to the prod servers, we are not able to check this.  we have placed a request for the prod support team to look into it.

Are there any other settings that could be causing the working folders to be set to c:\temp?  the GP service created using python (10.3?) was working well before the upgrade.

we are working closely with prod support team - we wanted to get more ideas while requesting them to make changes if necessary (all in 1 shot if possible).

regards

ravi.

0 Kudos
1 Solution

Accepted Solutions
JonathanQuinn
Esri Notable Contributor

If you ArcGIS Server site has multiple machines, you'd have UNC paths for the config-store and server directories, (including the arcgisjobs directory). Starting at 10.1, the local jobs directory is used, (C:\Users\<service account>\AppData\Local\Temp), when running GP services for performance reasons.

Performance tips for geoprocessing services—Documentation | ArcGIS Enterprise 

But as a task author, you no longer have to specify that your task use the local job directory as it is automatically used if the server participates in a cluster of more than one machine, or the directories are referenced using a UNC path.

The network traffic you see is expected, but the directories switching to C:\temp is not. It could be an artifact of something not going through correctly during the upgrade.

View solution in original post

14 Replies
by Anonymous User
Not applicable

So you upgraded from 10.3 to 10.5.1, is that right? Was this upgrade done using the same machine (ie all you did was upgrade the software on the same machines (no new machines))? And I imagine the service account running AGS has remained the same?

if you log into server manager, what are the registered directories? Is C:/Temp registered? If so, as what type of directory and for what services? You’re able to specify the services directories after the service is already published, so, worst case scenario, you can always re-specify the appropriate directories 

0 Kudos
Ravichandran_M_Kaushika
Occasional Contributor

Andrew Valenski,

good afternoon. the staff member mentioned to me that all 'directories' are pointing to \\MyNetworkShare\folders and no trace of c:\temp anywhere.

i asked the staff member to check whether the 'user' running the GP service has write permission to the folder(s). i will update the thread as i make more findings.

regards

Ravi.

0 Kudos
by Anonymous User
Not applicable

Hey Ravi -- would you be able to share the GP script that isn't working? I'm wondering if some arcpy.env setting changed for y'all and things getting written to 'in_memory//' are defaulting to a new spot

Ravichandran_M_Kaushika
Occasional Contributor

Thanks Andrew for the offer of help. i have attached PY files. it was written in mid to late 2014 if i am not wrong.

thank you for the help.

regards

ravi.

0 Kudos
Ravichandran_M_Kaushika
Occasional Contributor

Further to the python environment settings,  there is statement in py code:

self._ws = env.scratchFolder

(line 159 of elevation_async.py) ;

i didn't know where to check for the py  env being set. i searched the Python27 folder but could not make headway. 

hope it helps.

regards

ravi

0 Kudos
Ravichandran_M_Kaushika
Occasional Contributor

About the upgrade process:  here is the answer from the support staff member:

"This was an In place upgrade 10.4 to 10.5.1, no new machines. Service account was not changed. Service directories were not changed and are all still pointing to the file share."

0 Kudos
jorisfrenkel
Occasional Contributor II

Hi Ravi,

You mention the GP process and Python. I noticed recently that the Python path may be set incorrectly when upgrading from 10.3.1 to 10.5.1. Just let your prod team check it.

See this link: https://support.esri.com/en/technical-article/000013609

Regards,

Joris

0 Kudos
Ravichandran_M_Kaushika
Occasional Contributor

Thanks Joris, i will look at the link and do the needful.  thanks for your time.

regards

ravi.

0 Kudos
Ravichandran_M_Kaushika
Occasional Contributor

Joris and Andrew,

I went through the app when no one was using the app - and watched the network debug on the browser and saw that:

 

'C:\\Users\\S_SPRD~\\AppData\\Local\\Temp\\geoprocess\\dataextract_gpserver\\j4a463fb27ba448a2a5907f7f571c4c42\\scratch\\15SVA095230_286969_sa6.tif',

'C:\\Users\\S_SPRD~\\AppData\\Local\\Temp\\geoprocess\\dataextract_gpserver\\j4a463fb27ba448a2a5907f7f571c4c42\\scratch\\15SVA095245_286970_sa6.tif',

'C:\\Users\\S_SPRD~\\AppData\\Local\\Temp\\geoprocess\\dataextract_gpserver\\j4a463fb27ba448a2a5907f7f571c4c42\\scratch\\15SVA095260_286971_sa6.tif',

'C:\\Users\\S_SPRD~\\AppData\\Local\\Temp\\geoprocess\\dataextract_gpserver\\j4a463fb27ba448a2a5907f7f571c4c42\\scratch\\15SVA110215_286989_sa6.tif',

'C:\\Users\\S_SPRD~\\AppData\\Local\\Temp\\geoprocess\\dataextract_gpserver\\j4a463fb27ba448a2a5907f7f571c4c42\\scratch\\15SVA110230_286990_sa6.tif',

'C:\\Users\\S_SPRD~\\AppData\\Local\\Temp\\geoprocess\\dataextract_gpserver\\j4a463fb27ba448a2a5907f7f571c4c42\\scratch\\15SVA110245_286991_sa6.tif',

'C:\\Users\\S_SPRD~\\AppData\\Local\\Temp\\geoprocess\\dataextract_gpserver\\j4a463fb27ba448a2a5907f7f571c4c42\\scratch\\15SVA110260_286992_sa6.tif',

'C:\\Users\\S_SPRD~\\AppData\\Local\\Temp\\geoprocess\\dataextract_gpserver\\j4a463fb27ba448a2a5907f7f571c4c42\\scratch\\15SVA125215_287010_sa6.tif',

'C:\\Users\\S_SPRD~\\AppData\\Local\\Temp\\geoprocess\\dataextract_gpserver\\j4a463fb27ba448a2a5907f7f571c4c42\\scratch\\15SVA125230_287011_sa6.tif',

Many such rows - the prod support staff member told me that the process were running on a user that had access to the \\networkShare\folders\.

As per the previous posting of python script setting a scratchFolder:

self._ws = env.scratchFolder

I opened pyScripter and was trying to change the arcpy.geoprocessing.env.scratchfolder and I tried to reset or change it to another folder - it would not let me do it.

>>> arcpy.geoprocessing.env.scratchFolder = "D:\MyDownload"
Traceback (most recent call last):
  File "<interactive input>", line 1, in <module>
  File "D:\Program Files\ArcGIS\Server\ArcPy\arcpy\geoprocessing\_base.py", line 541, in set_
    self[env] = val
  File "D:\Program Files\ArcGIS\Server\ArcPy\arcpy\geoprocessing\_base.py", line 601, in __setitem__
    ret_ = setattr(self._gp, item, value)
AttributeError: Object: Environment <scratchFolder> cannot be set

thanks and regards

ravi.

0 Kudos