Getting Error running python script

Hi all,

I keep getting this error when running a python script:
External program failed with exit code 112; path=C:\Windows\py.exe; args="ProjectPython.py"; workdir=C\Public Folders\Default\16.Porject Python X
Location: action "Run program", table "Imported table 1"

the python runs properly executed via command or simple using sublime, but always gets this error in EasyMorph Server.

Any ideas? Thank you in advance.

Hi @JoMar ,

Exit code 112 usually means "There is not enough space on the disk" (ERROR_DISK_FULL 112 (0x70)). Without more details about the script or the environment, it is hard to determine what exactly is happening.

Taking this out of the icebox. That’s strange, I have around 100GB in the disk left. If I run the python manually, it runs perfectly fine.

What is needed regarding environment (Winserver 2019 running 32GB RAM and more than 100GB disk available).
Running current EM version.

Thanks.

I see. A few follow-up questions:

When you run it manually, is it on the same machine and under the same user account as the EasyMorph worker?

Can you replace C:\Windows\py.exe with the full path to the intended python.exe and 'ProjectPython.py' with absolute path then try again?

Does the same failure happen with a minimal script such as print("ok") launched in the same way?

Also, can you capture the output of the following PowerShell commands running on the server worker? There is a separate PowerShell action.

whoami
py --list
python --version
py -c "import sys, os, tempfile; print(sys.executable); print(sys.version); print('cwd=', os.getcwd()); print(tempfile.gettempdir());"

Does the script create temporary files, unzip files, generate logs, or write large intermediate files?

Any additional details about the data volume and the kinds of operations the script performs could also be helpful.

Just to clarify, ‘Run external program’ simply starts the specified executable with the provided arguments and working directory, under the Windows account the EasyMorph worker/service is running as. So if it behaves differently from a manual run, the cause is usually the execution context - account, environment variables, permissions, resolved Python installation, or working directory.