nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Python script performing oddly when run as a scheduled task on Windows Server

JeremyRead

I have setup a python script to run as a scheduled task on a server running Windows Server 2008 (which was ridiculously hard to do in itself). I can run the task manually and it does what it is supposed to do (export a bunch of Data Driven Pages as .pdfs), however it is *not* doing two of the things it is supposed to: 1. Open a console window while it's running, 2. Send an automated email when it is done. Now, if I just manually double-click on the script itself and run it, the command window opens and the email is sent without any issues.

Why does it not do these things when run as a scheduled task? Is there some sort of setting that I need to change? I'm finding scheduled tasks in Server 2008 to be very painful to try to use. I have none of these problems when running the script as a scheduled task in Server 2003.

Find more posts tagged with

Accepted answers

All comments

mvolz47

Ivan:

So the Program/script argument has the path to the bat file including the bat file name?

And the Start in (optional) argument has the path to the folder where the above bat file resides?

This is how I have my Scheduled Task configured in Windows Server 2008 and it executes successfully.

You are running with highest privileges?

VCGIvanBrown

Now the "Arguments" and "Start In" are blank. I did try setting the "Start In" to the full path of the script's folder. That did not make a difference. My script does not use arguments.

mvolz47

Ivan:

In the Actions tab of your Scheduled Task what do you have as the following entries (Please include full path):

Program/script

Add arguments (optional)

Start in (optional)

VCGIvanBrown

I tried switching to the 64-bit Python in the Path environment variable. The problem remained.

VCGIvanBrown

The problem even remains if I check out an ArcInfo license to this server (as opposed to using the license server, which is remote).

VCGIvanBrown

Yes. I tried wrapping the script with a .bat. It did not make a difference.

mvolz47

Are you using a bat file to call your python script?

Or are you calling the python script directly?

VCGIvanBrown

Yes. I have both Python 2.7.2 and the Python 2.7.2 64-bit installed to 2 different directories. The Python that is accessed by navigating through [Start | Programs | ArcGIS] is the 64-bit Python.

My Path environment variable did not include a path to the folder of the Python.exe of the non-64-bit Python; Path variable did not include a path to the 64-bit Python either. I added the non-64-bit Python path to my Path environment variable. My PYTHONPATH variable was pointing to a custom module folder of an old Python 2.6.x folder. I moved that custom module folder to my non-64-bit Python 2.7.2 installation and set PYTHONPATH accordingly (I don't think that this is a PYTHONPATH issue).

Still, same result.

StacyRendall1

PYTHONPATH is not the path to Python, simply a place that Python looks for libraries/scripts/modules.

Some information on this post might be useful: locating Python, adding to Path and accessing Arcpy

mvolz47

Can you look at the path C:\Python27 and see what directories are stored there?

There might be 2 - one for 32 bit foreground processing and one for 64 bit background processing (new at v10.1).

Then check your server's environmental variables and see what the value is PYTHONPATH is.

If PYTHONPATH is pointing to the 64 bit version of python (ArcGISx6410.1), this might be the problem as I believe the scheduled task is running the python script in the foreground.

VCGIvanBrown

Yes. I upgrade the license manager to 10.1. Also, ArcGIS Desktop will run on the problematic server.

mvolz47

Did you upgrade the license server to v10.1?

VCGIvanBrown

A Python geoprocessing script worked as expected on my Windows 2008 R2 Standard server before upgrading ArcGIS Desktop from 10.0 to 10.1 on that server.

Now, I can't get a Python script to run when I am not logged into the server (selected the option for the task to run whether user is logged in or not when making the task). The script only runs if the task is set up to run only if the user is logged in.

I experimented. The problem starts with the import of arcpy. Here is what happened. I scheduled a little script that doesn't use arcpy to write a little text into a text file. That script worked as expected when scheduled with the option to run whether or not the user is logged in.

Here is the tidbit of code:

   import sys

   def make_note(the_note):
      log_file = open(sys.path[0] + "\\test.log", "a")
      log_file.write(the_note)
      log_file.close()
      return None

   make_note("So far, just writing a line.\n")

Then, I added an import of arcpy to the script and scheduled the script again. The script stopped executing at the import of arcpy.

import sys

   def make_note(the_note):
      log_file = open(sys.path[0] + "\\test.log", "a")
      log_file.write(the_note)
      log_file.close()
      return None

   make_note("So far, just writing a line.\n")

   ***** SCRIPT STOPPED EXECUTING HERE *****
   import arcpy

   make_note("Now... after importing arcpy.")

I will note that the ArcGIS license server is on another server. However, the account that I am using can ping that license server okay. This wasn't a problem until after upgrading to 10.1. This is a big problem; It impedes our automation.

JeremyRead

Thanks again, Michael. This is very helpful!

mvolz47

Jeremy:

Here is a bat file example that calls a python script:

@echo off
set pyexePath="C:\Python26\ArcGIS10.0\python.exe"
set pylogPath="C:\GIS\ServerProcesses\Bezier_Removal\Bezier_Remover_Simplify.log"
set BezRemove_pyPath="C:\GIS\ServerProcesses\Bezier_Removal\01_Bezier_Remover.py"
echo Start time: %time% > %pylogPath%

REM Run the python script
echo ------  Update time: %time%
echo ------  Removing Bezier curves from RDCL in Transportation GDB  --------
echo ------  Removing Bezier curves from RDCL in Transportation GDB  -------- >> %pylogPath%

%pyexePath% %BezRemove_pyPath% >> %pylogPath%


echo End time: %time% >> %pylogPath%

Here is the python script that this bat file is calling:

# ---------------------------------------------------------------------------
# Bezier_Remover.py
# Created on: 2011-11-15 15:27:13.00000
#   (generated by ArcGIS/ModelBuilder)
# Description: 
# ---------------------------------------------------------------------------

# Import arcpy module
import sys, string, os
import arcpy
import arcpy.mapping
from arcpy import env

import smtplib #E-mail library

# Set environment
arcpy.env.overwriteOutput = True

# Local variables:
RDCL_SRCH__2_ = "RDCL_SRCH"

TRANS_RDCL_SRCH = r"\\Server\GIS\Enterprise\Data\transportation\Transportation.gdb\TRANSPORTATION_RDCL_SRCH"

try:

    print("Densifying TRANSPORTATION_RDCL to remove Bezier Curves")

    # Process: Densify
    arcpy.Densify_edit(TRANS_RDCL_SRCH, "DISTANCE", "25 Feet")

except:
    
    print arcpy.GetMessages(2)
    SUBJECT = "Road Densify Script Failed"
    TO = "person@mail.org"
    FROM = "Process_Server"
    text = "Removal of Bezier Curves in Roads failed" 
    BODY = string.join((
            "From: %s" % FROM,
            "To: %s" % TO,
            "Subject: %s" % SUBJECT ,
            "",
            text
            ), "")
    server = smtplib.SMTP('mail server address',mail server port #) #server = smtplib.SMTP(HOST)
    server.sendmail(FROM, [TO], BODY)
    server.quit()

This is a very simple script that I have had running successfully on my Windows Server 2008 server for about 2 months now. The script simply removes Bezier curves from a polyline feature class as the web application that uses this data, fails when working with Bezier curves. I hope this helps you to solve your problem

JeremyRead

Hello Michael,

Thank you so much for your reply. I am not calling the script from a batch file, but maybe that is how I should do it. Could you maybe post an example of how to do this in Server 2008?

Also, I spoke too soon about the automatically-generated email as it is not working at all. However, that may just be something I need to work with our Exchange administrator to resolve.

I had actually found an example online to run a Python script as a Windows service and I may still end up going that route. Apparently there are a lot of people out there who are frustrated with the clunkiness of the task scheduler in Server 2008.

mvolz47

Jeremy:

I am also in the process of migrating python scripts from a Windows Server 2003 server to a Windows Server 2008 server. I thought it was going to be a straight forward process, but it has been more difficult than I had expected.

Do you call your python scripts from a bat file? That is how I call my python scripts. I did not need to modify the python scripts in the Windows Server 2008 server environment, but I did need to modify my bat files that called the python scripts.

Some of the differences in the bat file syntax included:
1.) Need to call the python scripts using their full path - I was able to call the script in Windows Server 2003 because it recognized the relative path
2.) Need to call other dependent files (script log files) using their full path - I was able to call the script in Windows Server 2003 because it recognized the relative path
3.) In order to make the bat file code more readable, I set variables for the path to the python script and log files and used these variables to reference the files throughout the bat file (again due to the fact that relative paths to dependent files of the bat file are not recognized)

Unlike yourself, my code to generate an E-mail if errors were encountered worked without modification when I moved from Windows Server 2003 server to a Windows Server 2008 server

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.