I have a python script that starts a fullscreen animation when run - how do i set this to start at startup in ubuntu 16.04? Other answers to the "script on startup" problem don't work - because I'm assuming they're executed before the desktop environment has a chance to start up...
I have a script called "startup.sh" that reads as:
xrandr --output HDMI-0 -s 1280x1024
source activate demo
cd ~/demo/
python run.py
Where the first line sets the correct resolution - the second line activates an anaconda environment, the third line changes directory (parts of the script need it to be in that directory, and the 4th line finally runs the script that launches a fullscreen graphic (using pygame, if it matters.)
How can i set this to auto run after unity finishes setting up? Thanks so much... any help or comments at all are really appreciated...
EDIT: it looks like someone here had a similar problem: https://www.raspberrypi.org/forums/viewtopic.php?t=128602
They wanted to start a pygame script on startup - and were able to do so after their desktop environment loaded by putting a call to their program in ~/.config/lxsession/LXDE-pi/autostart - I'm not using LXDE - i'm on unity, so is there an equivalent?
Easiest way to run things at startup is to add them to the file /etc/rc.local.
But to do this properly, you should use the update-rc.d command. You may try it like this:
update-rc.d /path_to_script/script_name.sh start 2
Or use update-rc.d /path_to_script/script_name.sh defaults to create both startup and kill scripts all at once.
For more precise actions you can visit here for details information: http://manpages.ubuntu.com/manpages/xenial/man8/update-rc.d.8.html.
Related
I have a Python code running on Spyder on our server which needs to run constantly. However, from time to time our server breaks and it is restarted. Unfortunately, my code stops running as well and I need to restart Spyder and the code manually when opening it the next day.
Is there any way to restart the code automatically when the server is restarted?
Thank you a lot!
You can add as a crontab rule what you want to run after reboot.
You can use this line in crontab by using crontab -e command, if you use server running on Linux platform.
#reboot <your_python_file_path>
Simply utilize shell:startup and add your Python location + path there (or create a Batch script for it):
myprogram.bat:
python.exe main.py
Alternatively, if you don't have python location in your PATH env variable, utilize the full path:
myprogram.bat:
"C:\Program Files\Python39\python.exe" main.py
I use a RaspberryPi 3 with UbuntuMate 16.04. On it, I want to start a little Python (3.5) program every midnight. For that I call a little shell script, so that I can change into the wanted directory comfortably.
crontab:
5 0 * * * /path/to/script/start.sh
start.sh (yes, it's executable):
#!/bin/bash
cd /path/to/wanted/workingDir/
python3.5 ControllerQueue.py
#also tried: python3.5 ControllerQueue.py &
Now if I execute the programm or script from the terminal, everything runs fine. But if I use the crontab it starts the script and stops right after. I also tried running the programm directly but get the same outcome. The paths are correct as I copied the workingDir path from the crontab-file and started it via the terminal.
Is there something I overlook?
As stofvl suggested, I saved the error output of my shell script. It turns out that I needed to add a display. My programm is divided into two scripts. One which provides a GUI and the other main application. The script only starts the main application, without the GUI, but it seems that this didn't matter.
This discussion helped me solve the problem.
I wrote a python script that logs some data to a txt file with the absolute path /home/pi/foo.txt through button presses that trigger interrupts. I've started the script many times through the command line without any problems: when you press go, it goes, and when you press stop, it stops. The script is located in /home/pi/log.py. I wrote a shell script that will execute this python script because I read that it may help on a tutorial, so let's call it log.sh which calls
#! /bin/sh
cd /home/pi
/usr/bin/python /home/pi/log.py
However, when I attempt to start this script through crontab by adding it to my
#reboot log.sh
the script will run, but no button presses will stop the script (aka stop button won't work). The cpu usage goes up to 100% and sticks there. I've tried copying and pasting the environment variables from my user environment into crontab, but that won't work either.
Any ideas?
I learned the hard way that the environment that crontab uses isn't the same as your user's environment.
Check out this stack over flow for more info about environment difference between user and crontab: https://serverfault.com/questions/698577/why-is-the-cron-env-different-from-the-users-env/698635
The best thing in my opinion to do is to just do everything in python. There's a python environment that behaves like crontab. It's called schedule(https://pypi.python.org/pypi/schedule).
I'm actually using it in a raspberry Pi thermostat project.
check it out here:https://github.com/mababio/raspi_thermostat/blob/c6aea6ded6874d0dc21ded34f07874dd7f97dd15/src/thermo/test/jobs.py
So I have a python game (PyGame) running on a raspberry Pi.
I have followed the instructions found on many sites for getting the Raspberry Pi to auto login (those all work), auto run startx, but I'm stuck on getting my program to run once the GUI loads.
Many people (here on StackOverflow and other places) point to this presentation here:
http://www.slideshare.net/SeggySegaran/raspberry-pi-autostarting-a-python-program
I've tried both ways of doing it (putting the desktop file in autostart or putting the command in rc.local
I have opened up a Terminal window and copy / pasted the command to verify there are no typos and the code will run......
sudo python /home/pi/valley.py
and it will run. Is there a way to see a log to find out WHY the program doesn't launch? Is there a better way to get done what I want to get done?
I've got my python script to run at startup doing this:
sudo nano /etc/xdg/lxsession/LXDE/autostart
This will allow you to add an element to run when the LXDE desktop session begins (the raspian default GUI if setup to do from raspi-config)
It will probably have entries like these:
#lxpanel --profile LXDE
#pcmanfm --desktop --profile LXDE
#xscreensaver -no-splash
It's just a matter of adding your script there as well
#lxpanel --profile LXDE
#pcmanfm --desktop --profile LXDE
#xscreensaver -no-splash
#python /home/pi/yourAwesomePyScriptHere.py
If your python script uses GPIO, you need to run that as root (using sudo):
#sudo python /home/pi/yourGPIOScript.py
One thing I do want to point out: always test your script before hand.
I mean, run with the absolute path, make sure it still works, try to break it, make sure it's as robust as it can be. If there are errors in your script and you place it at start up you won't see those in a terminal window, but you will hog the cpu with python stuck in a loop at startup.
Also check out this answer on the RPi exchange
You can achieve this in two ways:
1). Using LXDE autostart.
2). As a service via init.d.
If you are starting X with "startx", you can also just stick your game in your .xinitrc. If your game binary is called "game" and is in your path, just do this:
echo "game" >> ~/.xinitrc
This works for other commands. Add a "&" if you want the command to keep running in the background.
This is how I start my window manager, load my wallpaper, start a compositor, etc. It is stupid simple, easy to change later, and can do anything you can do at a terminal prompt.
You can run your script automatically on startup of raspberry by using crontab.
Crontab is table that list all command to perform on scheduled time.
First, you need to edit crontab by using:
sudo crontab -e
And after this, add following line:
#reboot python path-of-your-script & (& should be at the end of line that means command will execute in background).
Save your script and reboot your system. When your system will start, your script will run automatically.
I have a python script file that works perfectly when I use it from the terminal.
Now I have created the following .desktop file in order to launch it easily:
[Desktop Entry]
Name=Test
GenericName=Test
Comment=My test script
Type=Application
Exec=/opt/test.py
Icon=/opt/test.png
Categories=Utils;
When I launch it the GTK window appear but clicking a button that call an init.d script make it working not properly.
Therefore adding Terminal=true make it working perfectly but I don't want to have that terminal open.
So I have then put the following code in order to log the environment variables:
import os
with open("/tmp/py_env.log", "w") as env_log:
env_log.write(str(os.environ))
and found differences.
So my question is how to write the .desktop file so that my application is running like if I start it from my terminal (without having an opened terminal :))
The problem is valid, but I think "replicating the terminal environment" is the wrong approach to solve it.
Indeed, what makes the application work is not the fact that it's launched from the terminal, it's that the terminal happens to have some environment variables which matter to your application.
Therefore, what you should aim for is to have those environment variables set properly at all times, rather than assuming the terminal environment will always happen to contain them all the time for all your users.
Thus, you should:
Check which environment variables are different between the two environments
Make a list of those which matter (i.e. those which would make the .desktop file work properly), and of what their value needs to be for the script to work
Either:
Create a wrapper script for your Python script, which initializes those environment variables properly, OR
Set those environment variables from inside the Python script itself.
this question is similar to .bashrc not read when shell script is invoked from desktop shortcut
either initialize your environment in ~/.bash_profile instead of
~/.bashrc
OR
make your *.desktop file call a wrapper that initializes your
environment - e.g. by sourcing ~/.bashrc (or whatever script is
responsible now).
the second solution is more specific (does not effect all other unrelated launches of your shell) in should thus be preferred.
Thanks anyone to have participate to this question.
I have solved this issue by implemented use of pkexec instead of gksudo.
pkexec seems to reuse the current user environment then I don't have this issue anymore.
Thanks.