1. Home
  2. Raspberry Pi Group
  3. Autostart python in lxterminal?

Autostart python in lxterminal?

I have tried a number of the methods that I've seen posted, but none seems to be working on my Pi-3 running the current Debian raspbian.

I'm using a script adapted from AndrewH7 to catch a power-down logic bit (emergency shutdown - impendling power loss). The script is called in /etc/rc.local. This works perfectly.

However my script, which has to run in a terminal - no go. I've tried a line in /home/pi/.config/lxsession/LXDE-pi/autostart: @lxterminal -e "/usr/bin/python /home/pi/proj/program.py"

and in /home/pi/.config/autostart/program.desktop [Desktop Entry] Name=program Exec=lxterminal -e "/bin/bash home/pi/program.sh" Type=Application {note that program.sh is a script: #!/bin/bash echo "Trying" >> /home/pi/evidence /usr/bin/python program.py If I run program.sh from a terminal/CLI, the python script starts and file "evidence" gets a "Trying" line added. Rebooting does not bring up the program, nor do I get the "Trying" evidence.

Within the LX-window interface, pulling up the LXSession configuration (Autostart section) shows these as enabled.

One important element is that the python script is using wxpython widgets that probably depend on running from a terminal, so methods that don't come from a terminal (like the rc.local) won't work.

I'd appreciate any clues you might have! -F

{this is for a device that has a touch screen - normally no keyboard nor mouse - to control a piece of research equipment. Trying to keep everything simple and obvious for the students and research techs who will use it}

Reply to
Frank Miles
Loading thread data ...

Should there be a / before home?

Reply to
Roger Bell_West

Call your program or startup script as the last action in the .bash_profile file belonging to the user where you want the Python program to run.

HINT: you won't see this file unless you run 'ls -a' and graphicla file managers can't see it unless you tell them to show filenames that start with '.'.

You'll still have to login to that user, but the program will start immediately you've done so. Stopping the program will leave you still in the console looking at a bash prompt. If you want to be logged out as soon as your program exits, just add the command "logout" immediately after the command that starts your Python program.

However, I strongly suggest that you create another user just to run this program and install the program and any date it needs in it. Otherwise you'll end up fighting with the auto start and stop in your normal pi login.

Also, if I was you I'd do the following:

- check that /usr/local/bin is in $PATH

- if it isn't, add it by either: - editing /etc/profile.d/path.sh so it gets appended to $PATH - editing .bash_profile to add the line "export BASH="$BASH:/usr/local/bin" appears before you try to run your program

- change your compile and build script/IDE setup/etc so that it copies the executable program to /usr/local/bin after a successful compile

because this makes sure that the program can be run under any user. In this case you'll want to be able to run it wherever you're compiling and testing it as well as in the user that runs it from the modified .bash_profile

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

Thanks; the original posting had no leading '/'. It makes no difference :(

Reply to
Frank Miles

Hey, that actually works! And it's so simple and (to this old guy) obvious. I was looking for something more Pi-centric, apparently unnecessarily. There's no .bash_profile; there was a .bashrc and a .profile; since /etc/profile called .bashrc midstream I added it to the .profile - and joy!! {My Debian desktop has a .bash_profile} [snip]

As indicated in my query, this is a dedicated device. Users will power the thing up and expect a particular set of functions that will be controlled by the GUI. They would be confused to see a full blown computer. If someone needs to change something, they can pop the lid, connect the network cable, SSH into it and -if necessary- change the .profile entry.

Thanks so much Martin! -Frank

Reply to
Frank Miles

I'm pleased that its got you going.

That was a calculated guess on my part: my RPi is upstairs and powered off, so I checked the filenames etc against the Fedora 25 powered laptop I'm sitting behind. I use a very similar arrangement to run an accounting package under a 68000 emulator on my house server (another F25 box), so was able double check the finer points against that.

Understood, so do it the other way round: make the 'pi' user into the captive login and move your development into another user, otherwise that captive login will really piss you off when it starts catching all logins, no matter how they get to the RPi.

My 68000 emulator is also accessed via a blind login across my LAN using an SSH session.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

I know this issue is old, but I have been trying to figure out how to get a python script to load using the LXDE-pi/autostart file, and I made it slig htly easy on myself to start by creating a /startup dir and a startup.sh th at runs all the stuff I want to open at startup. I was trying to run one of my scripts that does not have a GUI yet and just runs in the terminal. I w as trying to get it to open using the lsterminal --command="python3.7 -c '/startup/scripts/server.py; read'" and it wasnt doing anything, tried a fe w different variations of that command and nothing. I change it to lxtermin al -e python3.7 /startup/scripts/server/py & and it works fine now. Thanks for the help. :)

Reply to
koltin

On Thursday, 18 June 2020 at 12:15:31 UTC+2, snipped-for-privacy@bintegratedtech.com wro te:

a python script to load using the LXDE-pi/autostart file, and I made it sl ightly easy on myself to start by creating a /startup dir and a startup.sh that runs all the stuff I want to open at startup. I was trying to run one of my scripts that does not have a GUI yet and just runs in the terminal. I was trying to get it to open using the lsterminal --command="python3.7 - c '/startup/scripts/server.py; read'" and it wasnt doing anything, tried a few different variations of that command and nothing. I change it to lxterm inal -e python3.7 /startup/scripts/server/py & and it works fine now. Thank s for the help. :)

I have the same issue. Help is appreciated!

Reply to
Thomas De Jong

On Thursday, 18 June 2020 at 12:15:31 UTC+2, snipped-for-privacy@bintegratedtech.com wro te:

a python script to load using the LXDE-pi/autostart file, and I made it sl ightly easy on myself to start by creating a /startup dir and a startup.sh that runs all the stuff I want to open at startup. I was trying to run one of my scripts that does not have a GUI yet and just runs in the terminal. I was trying to get it to open using the lsterminal --command="python3.7 - c '/startup/scripts/server.py; read'" and it wasnt doing anything, tried a few different variations of that command and nothing. I change it to lxterm inal -e python3.7 /startup/scripts/server/py & and it works fine now. Thank s for the help. :)

I have the same issue. Help is appreciated!

Reply to
Thomas De Jong

What still works in Raspberry Pi OS is to put startup scripts in /etc/rc.local

Make sure to save your script somewhere where the root user can find it, like /usr/local/bin, or else specify the complete path. And make sure that it runs how you want it to run with that user and from that place. Test this by running: sudo myscript.py

Then put this as the second to last line in /etc/rc.local *before* exit

0: "myscript.py &". Make sure to add that space-ampersand.

You don't have to specify the python interpreter on the command line if you make the script executable (chmod 755 myscript.py) *and* it has a hash-bang as the first line: "#!/usr/bin/env python3" (without the quotes). It's probably safer to do that anyway since RPiOS still runs python2 as the standard version.

Also make sure your script doesn't have output, or it outputs to a file.

Reply to
A. Dumas

On Wed, 7 Jul 2021 14:25:07 +0200, "A. Dumas" declaimed the following:

I'd probably avoid any /etc/rc.* since they should be symlinked into the various run-levels, with both startup and shutdown scripts/options as run-levels change.

crontab using an @boot specification for "time to run", and maybe with a shell delay to ensure system is stable

@boot delay 60 && python script

and maybe redirect any output to a log file somewhere.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/
Reply to
Dennis Lee Bieber

Maybe they should but I expressly said this because on RPiOS rc.local is not. Old fashioned remnant or not, but it works and is way easier for anyone really.

Reply to
A. Dumas

into

Also, the /etc/rc.* were used by the UNIX V init system control scripts which wiere initially used by Linux, but which have now been obsoleted by systemd. While systemd does still run System V process control scripts, sooner or later they'll be obsoleted and will need to be replaced by systemd process control scripts so, it might be a god idea to use systemd process control scripts from the getgo. There's fairly decent, readable documentation for writing them here:

formatting link

A description of the cron daemon, which starts programs that you want to run at fixed times of the day or week can be seen by running "man cron" and "man 5 crontab" describes the files that control this process and what to put in them.

As an example, I use cron to fetch mail from my ISP every 10 minutes and also to do housekeeping tasks such as making daily backups at around 3AM every day, so that (a) I don't have to remember to do it and (b) this stuff gets done when I'n not using the machines for anything else.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.