I have a python3 program that I run without any problems on a headless raspberry pi configuration where I connect using ssh. I logon to my pi, start a tmux session, and run the program. It will run indefinitely. During development when an exception would occur I the python program would terminate and I would see the error info.
Now if my pi were to reboot while I wasn't around I would want it to run this program automatically. I implemented the following steps to make this happen:
I created a script which contains this line:
tmux new-session -d -s xbnw 'python3 /home/pi/python/XbNWSer05.py'
Then I modified /etc/rc.local to include this line:
sudo -u pi bash /home/pi/tmux_xbnw.sh
Now when I reboot my pi everything works for a few minutes. The program is clearly running. I can logon and attach to the session and see my debug output and everything looks fine.
After a few minutes though something goes wrong and if I'm logged on and connected to the tmux session I suddenly find myself at a command prompt as though the program never ran. Also the tmux session is no longer active. There's no indication what happened.
1) Am I starting my program improperly?
2) If so is there a way to figure out what happened?
Add a logfile, either hacky by hand or with the logger module. Then you can find out if the programm started and you can log every minute or so to see when it dies and what was the last state.
You can also check the syslog whether there was a reboot. I had a bad power supply cable which made my Pi reboot in past...
Related
I probably won't use the correct terminology here but here goes. I'm starting a program in tmux at boot time using crontab. Crontab runs a shell script to start tmux and then run the program. Later when I connect to the Pi everything is fine. When I connect to the tmux client though things look very different. In tmux the program is running fine but the environment is different. Up-arrow for example no longer brings up the last command and there are no colors in file displays. I figured out using printenv that the environment variables are completely different between the tmux session and the ssh session. So when tmux is run during boot it receives a completely different subset of environment variables than my ssh session when I subsequently logon.
I notice that if I create another tmux session it has the same environment as the other still running session which suggests maybe that the environment comes from the tmux server.
Can someone help me figure out how I could have tmux receive the appropriate environment variables during boot?
If I boot the os without starting tmux in crontab and then start an ssh session and then run tmux the environment variables are the same in both shells(?).
The SHELL variable in these cases is /bin/bash. In the Crontab-tmux session SHELL=/bin/sh.
I suspected the different shells (/bin/sh vs /bin/bash) had something to do with the problem. I didn't realize I could simply change the shell with a simple command. Turns out all I had to do was type /bin/bash on the command line and everything works normally.
Now I'll check to see if this works in the boot script.
I am currently trying to get a cron job working, so that the google assistant starts automatically after boot. For that I created this cron job which executes on reboot.
SHELL=/bin/sh
PATH=/usr/bin:/bin:/home/pi/Desktop:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
#Reboot lxterminal -t "Google Assistant" -e /bin/bash /home/pi/Desktop/init.sh
lxterminal will open a window with google assistant running within.
Here is my full cron job:
#!/bin/bash
SHELL=/bin/sh
PATH=/usr/bin:/bin:/home/pi/Desktop:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
source /home/pi/env/bin/activate
python3 /home/pi/assistant-sdk-python/google-assistant-sdk/googlesamples/assistant/grpc/pushtotalk.py
I already tried answers from similar problems and even specified the path variable for cron, but it still won't work for me. The script isn't the fault, when I execute it manually it runs fine.
The problem wasn't with cron, though I settled for using a systemd service instead.
What I didn't know was, that Lxterminal needed a initalized screen to work and due to the script running on boot it wasn't.
This is an easy fix. Either add an delay of 30 Seconds or other values, depending on your system, to the beginning of your script or simulate the display beeing initalized already with export DISPLAY=:1
I'm working on some tuning of my raspberry. So I decided that midori should start automaticly after autologin.
With startx it works without problems, but X is still to ressource hungry. So I'll start midori with xinit and matchbox.
As test, I use as user "pi" this command "xinit ./home/pi/startmidori.sh" and it works.
So I'll put this into my rc.local file.
There is the command "su -l pi -c xinit ./home/pi/startmidori.sh", this doesn't work. I don't know why, but xinit exit immediately after starting.
How can I solve this? In guides I find this kind of solution, but for it doesn't work. I tryed to run it as root but it doesn't work, too. I've no idea why.
Check this for more information: Running X from The X Window User HOWTO
In general you always need a wrapper and you must run X with root, since it needs raw access to hardware devices.
So I suggest you to install lightweight display manager like LightDM if possible it has almost no footprint and then easy you can set it up to auto login with desired user and run desired window manager like matchbox in your case.
I was trying to figure out how to run a program at boot, but after realizing this program is an infinite loop, I have no way of getting out, or back to the terminal. Right when I give the Pi power it just goes right to the program on a black background. I don't remember exactly what I did to make it run at boot, I believe I just added some code in a place right above something that said "exit 0" and below something that says "esac". I don't remember the command that even got me there. (I am new to the Pi and Python and have just been playing around..unsucessfully.)
If anyone could help me either delete this program or get me to be able to edit it so I can fix the infinite loop that would be great. I'd rather not have to completely over-write the sd card with a fresh raspbian. But like I said I can't do anything at boot, and Ctrl + C doesn't do anything nor Ctrl + Alt + Delete.
EDIT: When I put the SD card in my computer, I see a list of 11 files:
bootcode
cmdline
config
fixup
fixup_cd
issue
kernel
kernel_cutdown
kernel_emergency
start.elf
start_cd.elf
None of these mean anything to me...
Update: Looks like I failed to get that you want to interrupt the running bootprocess and stop the script.
The simplest idea would be to turn of the pi, unplug the sd card and plug it into your desktop, (re)move the script and boot again.
Processes spawned during boot are stored in scripts in /etc/init.d/.... These scripts are called by the init process, the first process on a Linux machine (PID:1)
But init starts not all scripts in /etc/init.d. This depends on the run level. On a debian system there are 7 run levels.
For every run level there is a folder called like:
/etc/rc0.d
...
/rc6.d
in which are softlinks to scripts from /etc/init.d are stored.
To remove a script from being executed on every boot you'll delete all links from that folders. Usually on debian systems this is done using the update-rc.d tool:
update-rc.d NAME_OF_INIT_SCRIPT remove
You should also have a look at the file /etc/rc.local
Alt + PrintScn + k to kill the process stuck running from rc.local
You can use the cmdline.txt.
First, add or modify the cmdline.txt file on your sd card. Add "init=/bin/sh", then restart your Pi, and you can see a command line prompt.
Type 'sudo nano /etc/rc.local' to edit the file, and comment or delete the line containing the error. After that restart.
I had exactly the same issue, couldn't quit the process using CTRL+C. I edited the cmdline.txt like stated above, but then the pi didn't load the necessary usb drivers for my keyboard.
So eventually I logged in over SSH to the pi, and modified my rc.local file that way.
In my case worked combination "Alt" + "F4", it stops the current session and opens the login screen
I had the same problem as explained at the beginning of this Post. My Python app was caught in an endless loop.
I tried the Ctrl+Alt+F2 Command as recommended in many posts found in Internet without any terminal window being open. Apparently, after many other trials and reboots I saw a glimpse of a Terminal window each time the loop of my application restarted. It was impossible to catch anything until I started recording the screen using the slow motion video of my mobile phone and, yes, a terminal window with the Linux prompt was active, and able to accept keyboard entries.
All I did was (almost blindly) editing the culprit file with the
sudo nano filename command
and entering some characters in order to actually corrupt such file, saving and closing it, a rebooting the Pi.
At the end of the boot, the file produced an error but the system kept ready to operate.
I was then able to fix the bug in a normal way.
It hope this may be useful to others. In my case it spared me of burning a new Raspbian and losing all my previous work.
I got myself stuck in exactly the same problem. Luckily I had the ssh enabled, apparently this is disabled by default on Raspbian Jessie, so this may not work for all.
The exit 0 is the line in /etc/rc.local where you would have added in the script that is now running in a continuous mode. If you can ssh into the Pi using Putty and the Pi's IP address then
sudo nano /etc/rc.local
Scroll down to the bottom of the file and remove the offending program, then sudo reboot
They way to prevent this issue from happening is to add an & (ampersand) to the end of the line to fork the process and run it as a separate process like so
python /home/pi/myscript.py &
as specified in https://www.raspberrypi.org/documentation/linux/usage/rc-local.md
The ampersand allows the command to run in a separate process and continue booting with the process running.
Here is the situation, I'm planning to use a simple script to start a program call "STAF", when the Suse system is fully booted. I have achieved this by putting it in the "/etc/init.d/", but this script is basically executed at the background, which means that I cannot see its progress.
When the "STAF" is started this way it works but it doesn't show any working progress when its running service (for example ping, or system backup), instead if I start the "STAF" manually by running the same script whit a terminal, the working progress of "STAF" can be seen on the terminal. Its sort of like the program needs to be started with a interactive terminal, but how can I make this starting process automatic and it should imitate human opening a terminal and run the script?
Sorry if I explained it poorly because its a confusing situation. Thanks.
First, go to the KDE Startup and Shutdown options under System Settings. Then add this command as a new startup script:
konsole -e bash nameofyourscript.sh
I believe the screen utility can do what you describe. Instead of running STAF on startup, you would run screen STAF. To open that terminal, you would run screen -ls to get the screen ID, and screen -r ... to open it.
(Disclaimer: I have not tried this.)