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.
Related
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...
I am attempting to install RetroPie as an app on Raspbian Stretch and I am done except for creating a desktop shortcut for it. The problem is that the only way to open RetroPie seems to be running a command in the command line. I can’t do it in terminal because it gives me an error saying that it can’t initialize the window. Is there a way to run a command line command as a shortcut or am I going to have to find another way of doing this?
P.S. Here is the tutorial that I followed to install RetroPie:
https://www.makeuseof.com/tag/install-retropie-app-raspberry-pi/
Probably your shell (on the raspberry) is GNU bash. So read the manual of GNU bash.
You probably want (once) to edit some Bash startup file (such as ~/.bashrc) to define functions and aliases there, and you could add executable shell scripts somewhere in your $PATH. I recommend having a $HOME/bin/ directory containing your scripts and executables, and have $HOME/bin/ early in your $PATH.
I can’t do it in terminal because it gives me an error saying that it can’t initialize the window.
Perhaps you need some display server (such as Xorg or Wayland) running (with a desktop environment or a window manager). You could run Xorg on your PC (on which you could install Linux) and connect to the raspberry using ssh -X then remote applications running on your Raspberry are displayed on your PC. IF your Raspberry is directly connected to a screen (via HDMI) you might run some Xorg server on it.
Is there a way to run a command line command as a shortcut
Yes, by making a shell alias or shell function or shell script. You need to understand how they work and change or create some appropriate file using some source code editor (I recommend GNU emacs, but the choice is yours and you might use any other editor such as vim, gedit, etc...): functions and aliases could be defined in your ~/.bashrc; shell scripts would usually have their own file with a shebang under your $HOME/bin/...
TLDR; how can I run a node process from the terminal, start a process from node, exit the node process and have the process be attached to the parent terminal?
I am writing a node terminal application which should end by starting a new terminal application (e.g. vim, emacs, tmux). I want this application to run as if is was executed manually in the terminal that started the node application.
My current workaround for tmux is to run the node application, which sets up a new tmux session and echoes a tmux attach-session command just before the application exists. The user can then type this command manually in the terminal and execute it. Now the tmux session runs attached to the terminal.
I would want to move the attach command into the node application, but have the same end results. I.e. the node application terminates and the tmux session runs attached to the terminal. This seems to me to be required to do the same for applications like emacs, vim, etc. Where I cannot decouple the setup and attach. (For all I know vim and emacs can handle this decoupling, and I would be interested in knowing, but the original question asks for a general solution for any terminal application).
By attached, I mean as if the command/program was executed manually in the terminal.
The POSIX exec solves this problem as #Amadan has commented above. This solution does not work on windows.
The following snippet shows an example of how to do this with the kexec module.
const kexec = require("kexec");
kexec("emacs -nw");
I'm writing a python script on Linux (debian) to install a few things, reboot, and then do more things.
I'm not sure if it's possible, but would I be able to say,
run all of my installers, reboot and resume my script from where it left off?
I would like for the user to not have to do anything (even log onto the machine, if at all possible)
Oh! Also, is there a way to keep(or Store) variables without storing them in plaintext?
Thanks!
One more way to execute your script at booting time by adding below line to root's crontab
#reboot /usr/bin/python /root/simple.py
simple.py -- script need to be executed.
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.)