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"
Related
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
If I run create a tmux session like this:
tmux new -d -s dev -n server -c ~/projects 'make run-server'
I now have a window running my make task. If I attach to that window and press ctrl+c, because I have remain-on-exit enabled, I will see "Pane is dead". :relaunch-pane will re-run make run-server, but what I really want when I press ctrl+c is to see the Bash prompt, allowing me to enter whatever command I want.
Is there any way to do this besides creating a generic window and typing the command manually each time I create it?
I was able to get this working by sending keys in a separate command:
tmux new -d -s dev -n server -c ~/projects
tmux send-keys -t dev:server 'make run-server' Enter
Ok everyone, here is an issue which bugged me for quite some time now:
I am trying to run a bash script, which stores certain values in variables, and then starts another command in a detached session, so that the script can continue running because the command takes ages to finish. That's all fine and nice, but the problem is that the command which should be run in the detached session contains variables. This is not a problem when using screen as the "session manager" (or whatever you want to call a program doing session management):
read -p "Session name:" sessionname
read -p "Filename:" filename
screen -S "$sessionname" -d -m nano "$filename"
works fine, opening nano in the detached screen as expected. But when i re-attach to the session and close it, my terminal is cleared and sometinmes some of the text from the file is barfed right before my cursor. I realized that this is an issue with how screen works, so i decided to switch to tmux, but now a whole new realm of prblems opens:
tmux new-session -d -s "$sessionname" nano "$filename"
works fine on cygwin, but on my raspberry 2b running raspbian jessie it throws this error:
usage: new-session [-AdDp] [-c start-directory] [-F format] [-n window-name] [-s session-name] [-t tar
get-session] [-x with] [-y height] [command]
and trying tmux ls afterwards to see if anything started gives me this on the raspberry:
failed to connect to server: No such file or directory
while on cygwin, if no sessions are running, it gives me this:
no server running on /tmp/tmux-197609/default
How can it be that tmux on two different plattforms behaves conmpletely different? Have i installed it wrong on the raspberry (sudo apt-get install tmux) ?
I am all out of ideas what might be the problem here, so any help is greatly appreciated. (Sorry for confused spelling & grammar, non-native english speaker here)
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.