Task Scheduler Running Multiple Instances on Windows Server: Python Script Execution

Prevent multiple instances of a Python script running via Windows Task Scheduler by configuring the task properties to prohibit concurrent execution. Set the "Allow running if already running" option to "Do not allow new instance." This ensures that if a previous run is still active, the scheduler skips the new trigger, eliminating duplicate processes without requiring complex scripting or external locks.

The Root Cause: Concurrent Execution

When a scheduled task executes a Python script through Git Bash (typically using bash.exe), the Windows Task Scheduler treats each trigger as an independent event. If your script takes longer than the interval between triggers—for example, a one-minute trigger firing while the previous minute’s job is still processing—the scheduler may launch a second instance. This results in race conditions, corrupted data files, or resource exhaustion on the server. The default behavior for many tasks allows these instances to run simultaneously unless explicitly restricted. This is particularly common with scripts that involve file I/O, network requests, or heavy computation. Without proper safeguards, you end up with multiple python.exe or bash.exe processes consuming CPU and memory unnecessarily. To resolve this, we must adjust the task configuration rather than modifying the script itself.

Configuring Task Properties

The most reliable solution lies within the Windows Task Scheduler interface. You need to modify the specific task responsible for executing your points.sh script. Follow these steps to prevent overlapping runs:

1. Open Task Scheduler: Press Win + R, type taskschd.msc, and hit Enter.
2. Locate Your Task: Navigate to the folder containing your scheduled task. It might be under "Task Scheduler Library" or a custom folder you created.
3. Edit Properties: Right-click the task and select Properties. Do not use the "Edit..." button in the action pane; use the main context menu to access all settings.
4. Settings Tab: Click on the Settings tab at the top of the window.
5. Concurrency Setting: Find the section labeled "Allow the task to be run if the task is already running."

By default, this dropdown is often set to "Do not start a new instance," which is what you want. However, if it is set to "Run new instance in parallel" or "Queue a new instance," change it immediately.

Choosing the Right Concurrency Option

There are three primary options here, and understanding them is critical:

• Do not start a new instance: This is the correct setting for preventing duplicates. If the task is already running when the next trigger fires, the scheduler ignores the new trigger. The next opportunity will be the following trigger cycle.
• Run new instance in parallel: This allows multiple copies of the script to run simultaneously. Avoid this unless your script is designed to handle multi-threading safely and independently.
• Queue a new instance: This places the new run in a queue behind the current one. Once the first instance finishes, the second starts. While this prevents overlap, it can lead to a backlog if tasks consistently take longer than the trigger interval.

For a simple Python script executed every minute, "Do not start a new instance" is the safest choice. It ensures that only one process exists at any given time. If you choose "Queue," be aware that missed triggers will stack up, potentially causing a surge of executions later.

Verifying Git Bash Execution

Since you are using Git Bash to execute points.sh, ensure that the command line arguments are correctly passed. Often, users configure the task to run bash.exe with arguments like --login -c "./points.sh". If the task is misconfigured, it might spawn a shell that hangs, keeping the process alive longer than necessary. Check the "Actions" tab of your task properties. Ensure the program/script field points to C:\Program Files\Git\bin\bash.exe (or your local Git installation path). In the "Add arguments" field, verify that you are invoking the script correctly. For example:

--login -c "cd /path/to/script && ./points.sh"

Using absolute paths within the script or changing directories explicitly helps avoid issues where the working directory is ambiguous. If the script fails silently, the bash shell might remain open waiting for input, which would block the task from completing and trigger the "already running" state indefinitely.

Monitoring and Troubleshooting

After applying the settings, monitor the task history. Open the "History" tab in the task properties to see recent events. Look for Event ID 106, which indicates the task started, and Event ID 200, which indicates it ended successfully. If you see multiple start events before an end event, the concurrency setting has not been applied correctly. If the issue persists, check if other tasks are launching the same script. Multiple tasks triggering the same executable can cause conflicts even if individual task settings are correct. Additionally, review your Python script for infinite loops or unhandled exceptions that might prevent graceful termination. A hanging script will hold the lock, causing subsequent triggers to be skipped, which might look like the fix is working but actually indicates a deeper problem in the code. For more details on general scheduling issues, refer to our guide on Python Script Not Running with Task Scheduler: How to Fix. Another useful resource is Scheduling a Task to Start a Batch File with Windows Task Scheduler, which covers similar foundational concepts for batch-based automation.

Frequently Asked Questions

How do I force stop a stuck Python script instance?

Use the Task Manager to find the specific python.exe process associated with your script and end it manually. Alternatively, use PowerShell with Stop-Process -Name python -IncludeUserName to target the user running the task, avoiding accidental termination of other Python applications.

What happens if I select 'Queue a new instance' instead?

The scheduler will wait for the current instance to finish before starting the next one. This creates a backlog if tasks are slow, potentially leading to a burst of executions once the system catches up, which can overwhelm resources.

Can I add a lock file inside my Python script?

Yes, creating a temporary lock file (e.g., .lock) at the start of the script and deleting it at the end is a valid software-level solution. However, configuring Task Scheduler is simpler and more robust because it operates at the OS level, preventing the script from even launching if a conflict exists.

Why does my task still run twice despite the setting?

This usually occurs if there are two separate tasks configured to run the same script, or if the task is triggered by both a schedule and an event log. Check the "Triggers" tab to ensure only one active trigger exists, and verify no other tasks share the same executable path.

Is it safe to use taskkill to remove duplicates?

No, using taskkill /f /im python.exe is dangerous because it terminates ALL Python processes on the server, including unrelated services or user applications. Always target specific process IDs or use Task Manager to kill only the relevant instance.