Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Autostart python in lxterminal?
766 views
Skip to first unread message
Frank Miles
Nov 16, 2017, 6:19:50 PM11/16/17
to
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}
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}
Martin Gregorie
Nov 16, 2017, 7:01:33 PM11/16/17
to
On Thu, 16 Nov 2017 23:19:49 +0000, Frank Miles wrote:
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 |
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 |
Frank Miles
Nov 16, 2017, 7:08:31 PM11/16/17
to
On Thu, 16 Nov 2017 23:34:39 +0000, Roger Bell_West wrote:
> On 2017-11-16, Frank Miles wrote:
>> Exec=lxterminal -e "/bin/bash home/pi/program.sh"
>
> Should there be a / before home?
Thanks; the original posting had no leading '/'.
It makes no difference :(
> On 2017-11-16, Frank Miles wrote:
>> Exec=lxterminal -e "/bin/bash home/pi/program.sh"
>
> Should there be a / before home?
Thanks; the original posting had no leading '/'.
It makes no difference :(
Frank Miles
Nov 16, 2017, 7:24:25 PM11/16/17
to
On Fri, 17 Nov 2017 00:01:29 +0000, Martin Gregorie wrote:
> On Thu, 16 Nov 2017 23:19:49 +0000, Frank Miles wrote:
>
> 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.
Hey, that actually works! And it's so simple and (to this old guy)
> On Thu, 16 Nov 2017 23:19:49 +0000, Frank Miles wrote:
>
> 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.
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]
> 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.
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
Martin Gregorie
Nov 16, 2017, 7:48:38 PM11/16/17
to
On Fri, 17 Nov 2017 00:24:24 +0000, Frank Miles wrote:
> There's no .bash_profile;
>
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.
> 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.
>
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.
> There's no .bash_profile;
>
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.
> 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.
>
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.
kol...@bintegratedtech.com
Jun 18, 2020, 6:15:31 AM6/18/20
to
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 slightly 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 lxterminal -e python3.7 /startup/scripts/server/py & and it works fine now. Thanks for the help. :)
Thomas De Jong
Jul 7, 2021, 7:57:09 AM7/7/21
to
On Thursday, 18 June 2020 at 12:15:31 UTC+2, kol...@bintegratedtech.com wrote:
> 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 slightly 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 lxterminal -e python3.7 /startup/scripts/server/py & and it works fine now. Thanks for the help. :)
I have the same issue. Help is appreciated!
> 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 slightly 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 lxterminal -e python3.7 /startup/scripts/server/py & and it works fine now. Thanks for the help. :)
Thomas De Jong
Jul 7, 2021, 7:57:27 AM7/7/21
to
On Thursday, 18 June 2020 at 12:15:31 UTC+2, kol...@bintegratedtech.com wrote:
> 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 slightly 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 lxterminal -e python3.7 /startup/scripts/server/py & and it works fine now. Thanks for the help. :)
A. Dumas
Jul 7, 2021, 8:27:04 AM7/7/21
to
On 07-07-2021 13:57, Thomas De Jong wrote:
> On Thursday, 18 June 2020 at 12:15:31 UTC+2,
> kol...@bintegratedtech.com wrote:
>> 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 [...]
> On Thursday, 18 June 2020 at 12:15:31 UTC+2,
> kol...@bintegratedtech.com wrote:
>> I know this issue is old, but I have been trying to figure out how
>
> I have the same issue. Help is appreciated!
What still works in Raspberry Pi OS is to put startup scripts in
> I have the same issue. Help is appreciated!
/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.
A. Dumas
Jul 7, 2021, 12:00:02 PM7/7/21
to
Dennis Lee Bieber wrote:
> On Wed, 7 Jul 2021 14:25:07 +0200, "A. Dumas"
> declaimed the following:
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.
> On Wed, 7 Jul 2021 14:25:07 +0200, "A. Dumas"
> declaimed the following:
>
>> What still works in Raspberry Pi OS is to put startup scripts in
>> /etc/rc.local
>
> I'd probably avoid any /etc/rc.* since they should be symlinked [...]
>> What still works in Raspberry Pi OS is to put startup scripts in
>> /etc/rc.local
>
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.
Martin Gregorie
Jul 7, 2021, 12:59:10 PM7/7/21
to
On Wed, 07 Jul 2021 11:30:59 -0400, Dennis Lee Bieber wrote:
> On Wed, 7 Jul 2021 14:25:07 +0200, "A. Dumas"
> <alex...@dumas.fr.invalid>
> On Wed, 7 Jul 2021 14:25:07 +0200, "A. Dumas"
> declaimed the following:
>
>
>>What still works in Raspberry Pi OS is to put startup scripts in
>>/etc/rc.local
>>
>
>>What still works in Raspberry Pi OS is to put startup scripts in
>>/etc/rc.local
>>
> 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.
>
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:
https://www.freedesktop.org/wiki/Software/systemd/
> crontab using an @boot specification for "time to run", and maybe with
> a shell delay to ensure system is stable
>
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
0 new messages