I have a Linux machine on GCP and followed this answer to add a startup script. When my file is the following it perfectly works and creates a log file when the machine starts:
#!/usr/bin/python3
with open('./my_log.txt', 'w') as f:
f.write('Hello Saeed\n')
f.close()
However, when I change it to any other files like:
#!/usr/bin/python3
from package import *
import numpy as np
import pandas as pd
I do not see the run file on my python process when the machine starts. I use ps -fA | grep python to see my python processes.
Can you please help me to figure this out?
Edit:
I import some packages it does not work.
I would recommend you check out the "official" way to install and run a startup script on a GCE VM: https://cloud.google.com/compute/docs/instances/startup-scripts. Using a cron job might work, but it's sort of a "low-level" solution given that GCP provides more managed and theoretically more straightforward ways to provide a script that should be executed every time your VM starts up.
As per your script, it might be a couple of things: either it finishes executing before you have a chance to run ps -fA | grep python, or it may be failing for some other reasons, probably missing dependencies. You can try the following test: run your script as root with sudo ./your_script.py. You should be able to see some errors and then you can start troubleshooting those to find a solution to your problem. The reason you need to run the script as root is that startup scripts are run as root, and thus such a test will represent what will happen at startup time more closely.
If you see missing dependencies problems you should be able to solve them by installing the python dependencies (like numpy) at the system level using a command like sudo pip install numpy. If you don't want your script to run as root you can also add the username that you want your script to be run as after the command in the crontab:
#reboot /path/to/script username
Hope this gets you on the right path :)
I have a bash script (clean.sh) that runs fine by hand but doesn't run when run from cron.
cd /usr/share/clean_addr/bin/
cleanme cleanme.ini
When the clean.sh script is by cron the cleanme exe is not found. I gave an absolute path to the cleanme exe but then its supporting library files were not found.
cd /usr/share/clean_addr/bin/
/usr/share/clean_addr/bin/cleanme cleanme.ini
The cron runs under the same user account as that in which the script ran manually. What do I need to set to get this to work.
Sincerely,
Stephen.
The answer is that the cleanme application required environment variables that were set on the user account, but were not known by cron because cron doesn't resolve those settings. Explicitly setting the environment variables for cleanme in the .sh resolved the issue
CLEANME_PATH=/usr/share/clean_addr/bin/
export CLEANME_PATH
I'm trying to set up a recurring Python task through windows task scheduler.
I have had success when I input the path to 'python.exe' and provide the script's path as a parameter to windows task scheduler (see screenshot below)
However, I want to be able to choose a particular virtual environment in which to run the script. I don't have much knowledge of venv, and I typically use it by opening cmd and running Scripts\activate.bat in the desired virtual environment directory.
How can I accomplish 'run task x in venvxxx every 24 hours' using windows task scheduler?
Create batch file with these commands:
c:\__full_path_to_virtualenv__\Scripts\activate.bat && python __full_path_to_python_script__.py
&& means run command2 if command1 completed successfully.
Then set that batch file as script to run. You don't need to set any additional arguments in task scheduler (or you can set them in batch file anyway) and can set Start in if script has to read/write from specific directory and uses relative paths.
Though the answer by mx0 above seems to work, I have set up Task Scheduler to run a flask web app on bootup. In this case, manual starting works fine, but manual ending does not. Ending the task kills the cmd.exe task that sets up the virtual environment, but the python.exe continues to run.
The solution that I found worked was from this reddit post which skips the virtual environment activation to call the python executable directly:
path\to\venv\Scripts\python.exe path\to\script.py
I'm not sure how robust this will be, but at least this way ending the task will end the python.exe
This is more verbose but very easy to understand, and - I found the most important - much easier than using Windows Task Scheduler settings when you have lots of scripts. To create another you just copy the .bat file and change one line.
Save this as a .bat file and point to it under Actions > Start a Program > Program/Script:, with no arguments or "Start in" necessary.
set original_dir=%CD%
set venv_root_dir="C:\Python-Venvs\env-name"
cd %venv_root_dir%
call %venv_root_dir%\Scripts\activate.bat
python your_script.py <arg1> <arg2>
call %venv_root_dir%\Scripts\deactivate.bat
cd %original_dir%
exit /B 1
For an installed command-line program, you can replace python your_script.py <arg1> <arg2> ... with <program name> <arg1> <arg2> ....
In addition it's simple to add another script on the following line, rather than attempting to parse sequential scripts into a one-liner for Task Scheduler.
I tried with mx0's answer and it works fine as long as your script does not take too long to finish.
I use a different approach in the task scheduler instead using batch files:
In "Program/script" textbox you set the path to Python executable (in my case is inside the virtualenv folder).
"Add arguments" => Just the name of your Python script (name.ppy).
"Start in" => The full path of your Python script (without the name.py).
This way the script runs and wait until the end.
My solution is almost identical to mx0, but I've added an extra step to ensure environment parameters each time. Edit the path/to/app for the app_path variable.
It may be a little redundant to check the environment setup every time, but I like ensuring my environment is set.
Simply schedule the execute_app.bat file or run in the cmd prompt. Deactivate command is not needed unless running from an Anaconda prompt. If you use a full path for path/to/app this file can be executed from any directory. I also have a Linux solution using execute_app.sh file below from a terminal.
This answer has been edited to simplify, and to use variables to make this easier to adapt to new projects.
App structure:
app/bin/app.py
app/bin/execute_app.bat
app/env/requirements.txt
# execute_app.bat file
# windows solution
SETLOCAL
set app_path=path/to/app
set env_path=%app_path%/env
set activ=%env_path%/Scripts/activate.bat
set req=%env_path%/requirements.txt
set app=%app_path%/bin/app.py
py -m venv %env_path% && %activ% && python -m pip install --upgrade pip && pip install -r %req% && python %app%
ENDLOCAL
#!/bin/bash
# execute_app.sh file
# Linux solution
app_path='path/to/app'
env_path=$app_path'/env'
activ=$env_path'/bin/activate'
req=$env_path'/requirements.txt'
app=$app_path'/bin/app.py'
python3 -m venv $env_path &&
. $activ &&
python3 -m pip install --upgrade pip &&
pip install -r $req &&
python $app &&
deactivate
The selected answer for this question is not correct. If you review the comments, you'll see the problem.
My answer builds off of #Nick P's answer (the #2 answer currently). His batch file will work, but you'll want to change the exit code from 1 to 0 if you want Windows Task Scheduler to report the task completed successfully. Also, simply calling the .bat file on the "Program/Script" line will not work. Instead, you need to put the name of your shell as the "Program/Script" to run (for instance, cmd), then put "/c name-of-batch-file.bat" goes in the "Add arguments (optional):" field. And finally, put the path to the batch file (minus the file name) in the "Start in (optional):" field.
It should look something like this:
REM Windows batch script to run 1+ Python program/scripts, sequentially, within
REM their virtual environment. This can be called from Windows Task Scheduler.
set original_dir=%CD%
set venv_root_dir="C:\Users\myUsername\myProjects\nameOfProject"
cd %venv_root_dir%
call %venv_root_dir%\Scripts\activate.bat
python nameOfPythonProgram.py
call %venv_root_dir%\Scripts\deactivate.bat
cd %original_dir%
exit /B 1
Copied this from nmpowell on github and it works fine. Run from task scheduler
Solution
Patching the path is all necessary.
The quick way would be a bat script that source environment activation script at the beginning
#call PATH_TO_MY_VENV/bin/activate.bat
python app.py
Proceeding Problem
Later you will realize that the python job starts fine, but won't stop when Windows Scheduler stop it.
When taskengine.exe decides to stop the job, the intermediate cmd.exe (bat script) process is killed and the Python.exe will be left straw. since the cmd.exe(bat script) won't signal python.exe to stop on exit.
Final Solution
Let Windows Task Scheduler or taskengine.exe launch python.exe directly without a middle-man script.
Previous answers launch python.exe directly with py script, this works for simple modules, but not for some binary module in conda environment.
For binary modules in conda to work, you can create a utility module named e.g. patch_conda_path to patch PATH variable in os.environ based on sys.base_exec_prefix. Copy the patching work that activate.bat does, just in python.
below example has been tested for conda virtual environment:
import is, sys
conda_base = sys.base_exec_prefix
subps = [";", "library\\mingw-w64\\bin;", "library\\usr\\bin;", "library\\bin;", "scripts;", "bin;", "condabin;"]
conda_paths = ""
for p in subps :
_p = os.path.join(conda_base, p)
if _p in os.environ["PATH"]:
continue
else:
conda_paths += _p
os.environ["PATH'"] = conda_paths + os.environ["PATH"]
Import this module at the beginning of your main script.
import patch_conda_path
... original main script ...
In task scheduler set
program to ... conda environment path...\python.exe,
arguments to your py script file name and
start in to your py script folder.
I am trying to make python3 executable scripts and run them from shell.I have python 3.4.0 installed on my system.
So, I added '/home/spandan/python_codes' directory to PYTHONPATH, as I am planning to keep my scripts and modules here.
However, while trying to execute these, the above error is thrown by the system, and the scripts wont execute unless I go into the python_codes directory and then execute them.
Executing python program : Here I found out that PYTHONPATH is irrelevant while making scripts, and also how to set the python shebang. So I set mine as #!/usr/bin/env python3.4.0
Is it correct?
You don't have to put your python codes in a global path. Just make your python 3.4 interpreter interpreter available globally. For that, edit .bash_profile or .bashrc file in your home directory and add the following line:
export PATH=${PATH}:/usr/bin/python3
That will make python3 executable irrespective of your current working directory.
In order to execute code from your codes directory, you just have to write:
$ python3 ./your_code.py
Another way is to add the shebang at the top of your code as
#/usr/bin/python3
and change the permission to executable by the current user (by default it will not have execute permission).
$ chmod 744 your_code.py
and then executing the script directly as
$ your_code.py
I hope I could address your problem.
Another way to do it is to use python-is-python2 or python-is-python3 debian packages with /usr/bin/env python sheabang.
This option will let the end user select which interpreter he want to use while maintaining your code versionless and avoiding some people to install unwanted interpreter versions.
As an example, run this commands to make a sample file:
cat << EOF > version.py && chmod +x version.py
#!/usr/bin/env python
import sys
print(sys.version)
EOF
And run the following command if you want to set python2 as default:
sudo apt install python-is-python2
Or run this command if you want to set python3 as default:
sudo apt install python-is-python3
Finally you could see the python interpreter version that you have been selected by running:
./version.py
The only drawback of this solution is that you could make your python scripts compatible across python interpreter versions, but thats your decision!
You can install which you want and change from python2 to python3 and vice- versa as you want, but the idea is to fix a python interpreter version in a system and not change it again unless definitive upgrade.
References:
https://askubuntu.com/questions/1296790/python-is-python3-package-in-ubuntu-20-04-what-is-it-and-what-does-it-actually
I am trying to launch a .sh script from Python 3.3 in Ubuntu 13.10.
The script is supposed to shutdown the computer. I have already marked the sh script as executable through the terminal. I have tried to run the sh script through: os.system("script.sh"), subprocess.Popen("Script.sh"), and subprocess.call([script.sh]).
They keep returning the: OSError Exec format error.
Any help would be greatly appriciated!
I assume that script.sh isn't in your PATH but in your current working directory.
By default os.system and subprocess look in your path for the requested executable. So to execute something in your current working directory you need to specify the executable like this:
subprocess.call("./script.sh")
The ./simply says that the executable that should be executed is in the current working directory.