I'm trying to write my own .tmux.config file and have managed to get most of it working (the file is quite simple). The intention is to have a minicom session running on the right side, whilst simultaneously saving the communication into a file. There is one problem. I define a UART_LOGFILE_NAME variable in my .bashrc file and export it, however, tmux still returns invalid environment variable. Is there something I'm missing?
my .tmux.conf file looks somewhat like this:
new-session -s serial -n console
split-window -h -l 30%
send-keys "sudo minicom rasp.serial -C ${UART_LOGFILE_NAME}"
split-window -v -l 10%
I can't find anything relevant in tmux manual entry except for the GLOBAL AND SESSION ENVIRONMENT. Also, sice I'm using the send-keys command I thought that the .bash_profile and therefore .bashrc files have been sourced before the minicom is launched (I have already managed to get the minicom running without logging and all panes have the UART_LOGFILE_NAME variable correctly defined after when I run tmux without logging of minicom session).
Thank you for your help
I want to run a python script in a tmux session on startup when launching my google cloud vm. I have searched around stack overflow and found this piece of code.
#! /bin/bash
sudo -H -u MyUser tmux new-session -d -s discord 'python3 MyFile.py'
I placed this in the meta data part of my vm where startup_scripts go but it doesn't launch when i start my vm. However when I run this code in the terminal after my vm has started it does exactly what I want it to do. What am I missing here?
After digging around for I while I found the problem. The command runs in the root directory so, before your piece of code, you have to add:
Add: cd home/username
Before your code.
I have used screen to start a server process, to witch I can later attach if needed and deatach again to carry on with other things. It worked fine but I have found byobu recently and I really love it.
I want to use the same kind of scripts to run the server but instead of a screen sesson I would like to attach it to a byobu tab.
I'm using byobu-tmux (because it looks better). How could I do it?
My original scripts (they both do more, but these are the relevant parts):
# Startup
screen -a -dmS <name> <command>
# Attach
screen -x <name>
I'm using Ubuntu server 16.04
I don't know screen commands, so here is a quick sample commands for byobu:
To create new tabs (called screens) inside the current session you can:
byobu new-window "ls -la && sleep 5"
To start a new session (new byobu instance you can attach to) with a command you can:
byobu new-session -s "session name" "ls -la && sleep 5"
To create it already detached:
byobu new-session -d -s "session name" "ls -la && sleep 5"
To attach to a session by name:
byobu attach -t "session name"
There's possible duplicate but it's closed and unanswered.
As I'm using chef for automation, would be nice to automate tmux launch with pre-launched python web server and second window opened. (this is specifically for my development environment). And only way of doing this probably specifying parameters from command line.
Commands which I want to execute are in window with title "daemon":
source bin/activate
cd project
DEBUG=1 python app.py
I'm unable to find which command line parameters allows to pre-execute commands when launching tmux, and also to open more windows on launch.
You want to create a session without attaching to it (using the -d option), so that you can send additional tmux commands to open the second window before actually attaching.
tmux new-session -t mysession -d 'source bin/activate; cd project; DEBUG=1 python app.py'
tmux new-window -t mysession
tmux attach-session -t mysession
I'm currently trying to ssh into a remote machine and run a script, then leave the node with the script running. Below is my script. However, when it runs, the script is successfully run on the machine but ssh session hangs. What's the problem?
ssh -x $username#$node 'rm -rf statuslist
mkdir statuslist
chmod u+x ~/monitor/concat.sh
chmod u+x ~/monitor/script.sh
nohup ./monitor/concat.sh &
exit;'
There are some situations when you want to execute/start some scripts on a remote machine/server (which will terminate automatically) and disconnect from the server.
eg: A script running on a box which when executed
takes a model and copies it to a remote server
creates a script for running a simulation with the model and push it to server
starts the script on the server and disconnect
The duty of the script thus started is to run the simulation in the server and once completed (will take days to complete) copy the results back to client.
I would use the following command:
ssh remoteserver 'nohup /path/to/script `</dev/null` >nohup.out 2>&1 &'
#CKeven, you may put all those commands on one script, push it to the remote server and initiate it as follows:
echo '#!/bin/bash
rm -rf statuslist
mkdir statuslist
chmod u+x ~/monitor/concat.sh
chmod u+x ~/monitor/script.sh
nohup ./monitor/concat.sh &
' > script.sh
chmod u+x script.sh
rsync -azvp script.sh remotehost:/tmp
ssh remotehost '/tmp/script.sh `</dev/null` >nohup.out 2>&1 &'
Hope this works ;-)
Edit:
You can also use
ssh user#host 'screen -S SessionName -d -m "/path/to/executable"'
Which creates a detached screen session and runs target command within it
What do you think about using screen for this? You could run screen via ssh to start the command (concat.sh) and then you'd be able to return to the screen session if you wanted to monitor it (could be handy, depending on what concat does).
To be more specific, try this:
ssh -t $username#$node screen -dm -S testing ./monitor/concat.sh
You should find that the prompt returns immediately, and that concat.sh is running on the remote machine. I'll explain some of the options:
ssh -t makes a TTY. screen needs this.
screen -dm makes it start in "detached" mode. This is like "background" for your purposes.
-S testing gives your screen session a name. It is optional but recommended.
Now, once you've done this, you can go to the remote machine and run this:
screen -r testing
This will attach you to the screen session which contains your program. From there you can control it, kill it, see its output, and so on. Ctrl-A, then d will detach you from the screen session. screen -ls will list all running sessions.
It could be the standard input stream. Try ssh -n ... or ssh -f ....
For me, only this worked:
screen -dmS name sh my-script.sh
This, of course, depends on screen, and lets you attach later, if you ever want stdin or stdout. Screen will terminate itself when my-script.sh ends.
Below is a much more common decision that required some efforts to find, and it really works for me:
#!/usr/bin/bash
theScreenSessionName="test"
theTabNumber="1"
theStuff="date; hostname; cd /usr/local; pwd; /usr/local/bin/top"
echo "this is a test"
ssh -f user#server "/usr/local/bin/screen -x $theScreenSessionName -p $theTabNumber -X stuff \"
$theStuff
\""
It sends $theStuff list of commands to the tab No $theTabNumber of the screen session $theScreenSessionName preliminarily created at the 'server' on behalf of 'user'.
Please be aware of a trailing whitespace after
-X stuff \"
that is sent to overcome a 'stuff' option's glitch. The whitespace and $theStuff in the next line are appended by 'Enter' (^M) keystrokes. DON'T MISS 'EM!
The "this is a test" message is echoed in the initial terminal, and $theStuff commands are really executed inside the mentioned screen/tab.