I've looked up every tutorial i've found but none of them really answer my question.
I'm looking for a way to make a script which will :
Create a screen
Launch a "nodejs file.js" command in it
Distach
Make the screen accessible to every user from the group "devs"
For now here is the shell script I wrote :
#!/bin/bash
# Launcher script for js bot
screen -c ./_shared-conf/multi-screen.conf -dmS botScreen
screen -r botScreen
screen -d -m nodejs init_bot.js
and in the multi-screen.conf :
multiuser on
acladd rackover # adding every user manually as i don't know how to add group
acladd jj
Can you help me ? Thanks
Edit : I've been trying with TMUX, so far i've tried this :
Again, Alice and Bob ssh into the same server
Alice, as before, creates a new tmux session: tmux new -s alice. tmux will
implicitly create a new window group
Bob does not join that same session. Instead he starts a new session and
connects that session to the same window group as Alice’s session: tmux new -s bob -t alice
But this doesn't work neither.
The issue seems to be that your shell script will only launch the bot after you exit the screen. Let's go over what the commands do.
screen -c ./_shared-conf/multi-screen.conf -dmS botScreen
This creates a screen with the given config and doesn't attach.
screen -r botScreen
This attaches to the screen created before and thus waits until you exit or detach (Ctrl+A, D) from the screen.
screen -d -m nodejs init_bot.js
This creates another detached screen that runs the script.
The solution is to do it all in one command. To simply run the bot and then terminate the screen after the bot stops, add the nodejs command at the end:
screen -c ./_shared-conf/multi-screen.conf -dmS botScreen nodejs init_bot.js
If you want the screen to keep running after the bot stops, then you can use the solution from here:
screen -c ./_shared-conf/multi-screen.conf -dmS botScreen sh -c 'nodejs init_bot.js; exec bash'
This will run sh in the screen with the bot, then when the bot terminates runs bash to get an interactive shell within the screen.
Related
I am trying to open multiple tabs and execute a series of commands in each tab. Lets say I open 3 tabs tab1, tab2, tab3. Then in each tab I would like to execute following:
ssh user#address (PublicKey Authentication is setup and
hence no need to enter password)
Launch python scripts (python some.py)
Hold the tab open after executing the commands to see the outputs.
I went through some threads and have a rough outline for Bash script.
#!/bin/bash
echo "Script running"
gnome-terminal -e "bash -c \"ssh user#address; uname -a; exec bash\""
When I run the above script, a new terminal opens and I can see that I have ssh-ed into the target address but the other command uname -a didnot execute.
I would like to build upon this to implement the following:
Open multiple tabs and run commands. Ex : gnome-terminal --tab -e
"bash -c \"ssh user#address; python file1.py; exec bash\"" -tab -e
"bash -c \"ssh user#address; python file2.py; exec bash\""
Wait for one of the python file to start executing before opening
another tab and repeating the process for another python file.
Also is there a better way to implement the same task ?
The above code snippet was from this thread.
You should consider using screen or tmux or a similar terminal multiplexer for this.
Example usage:
screen -d -m bash -c 'ls; bash'
to initiate a screen session in which ls was executed and then a shell started, and then
screen -X screen bash -c 'date; bash'
to create a new window in the existing screen session, run date therein and then start a shell in that window.
Mind that the programs are run without you seeing their output right away on your controlling terminal. You can then attach to the screen session using
screen -x
Which attach you to the running session and will show you one of the screen windows (the virtual terminals of your two running programs). Typing Ctrl-A n will switch through the windows, Ctrl-A d will detach you again, leaving the programs running, so you can attach later with screen -x.
You can attach from several locations (e. g. from two different Gnome-terminals) to the same running windows. Both will then show the same contents.
Another advantage of using screen is that you can log out and the programs keep running. If you later login again, you can still attach to the running sessions.
Only a direct attack like a reboot, a kill-signal or an interaction (like pressing Ctrl-C while being attached) will terminate your programs then.
I have a game server running in an xterm window.
Once daily I'd like to send a warning message to any players followed after a delay by the stop command to the program inside the xterm window from a script running on a schedule. This causes the cleanup and save functions to run automatically.
Once the program shuts down I can bring it back up easily but I don't know how to send the warning and stop commands first.
Typed directly into xterm the commands are:
broadcast Reboot in 2 minutes
(followed by a 2 minute wait and then simply):
stop
no / or other characters required.
Any help?
Do you also need to type something from the xterm itself (from time to time) or do you want your server to be fully driven from external commands?
Is your program line-oriented? You may first try something like:
mkfifo /tmp/f
tail -f /tmp/f | myprogram
and then try to send commands to your program (from another xterm) with
echo "mycommand" > /tmp/f
You may also consider using netcat for turning your program to a server:
Turn simple C program into server using netcat
http://lifehacker.com/202271/roll-your-own-servers-with-netcat
http://nc110.sourceforge.net/
Then you could write a shell script for sending the required commands to your "server".
If you know a little about C programming; I remember having once hacked the script program (which was very easy to do: code is short) in order to launch another program but to read commands from a FIFO file (then again a shell script would be easy to write for driving your program).
Something you might try is running your program inside a screen session.
You can then send commands to the session from cron that will be just
as if you typed them.
In your xterm, before launching the program do:
screen -S myscreen bash
(or you can even replace bash by your program). Then from your cron
screen -S myscreen -X stuff 'broadcast Reboot in 2 minutes\n'
sleep 120
screen -S myscreen -X stuff 'stop\n'
will enter that text. You can exit the session using screen -S myscreen -X quit
or by typing ctrl-a \.
screen is intended to be transparent. To easily see you are inside screen, you can
configure a permanent status bar at the bottom of your xterm:
echo 'hardstatus alwayslastline' >~/.screenrc
Now when you run screen you should see a reverse video bottom line. Depending
on your OS it may be empty.
How can I send the signals of CTRL-A and CTRL-D from a shell script to a screen?
Next code doesnt work to me. Screen process still is running in foreground and I want that it executes in background. Any idea?
#!/bin/sh
#TweetBot notifications with Growl
cd ~/node-tweetbot/
screen -S "tweet" node app.js -X stuff "'^A' '^D'"
You could simply start up screen in detached mode. From the man page:
-d -m Start screen in "detached" mode. This creates a new session but
doesn't attach to it. This is useful for system startup
scripts.
So this:
screen -S tweet -d -m node app.js
Would start up your screen session detached. You could attach to it at a later time by running:
screen -x tweet
I am trying to create a screen session/window from the shell and launch a command in it. How would I do that?
If you want to launch and connect to screen:
screen CMD
If you want to launch and not connect to screen:
screen -dm CMD
Works with sessions too:
screen -Sdm NewDetachedSessionName CMD
You can send keypresses to CMD with stuff:
screen -S NewDetachedSessionName -X stuff "keypresses"
To send a new-line, include \n or ^M or $'\n' with the keypresses.
first create new session :
screen -dmS [session_name]
then attach command or script to run in session created :
screen -x [session_name] [script.sh]
The main problem I'm having is to background a screen session from Hudson-CI. The shell steps are that I need to start a screen session from a script that is launched by another script. Heres' a simple test:
test.sh:
#!/bin/bash
myscreen.sh
myscreen.sh:
#!/bin/bash
screen -dm -S myscreen pingit.sh
pingit.sh:
#!/bin/bash
ping google.com
If I run ./myscreen.sh I get a screen launched that runs the ping continuously without a problem.
If I run ./test.sh, the screen is never started. I'm assuming there's something basic that I'm either forgetting or not understanding, but I can't figure out what. I thought this would work.
The real reason I want to do this is to have Hudson CI launch a continuous-test script which starts as a screen session so that it can continue in the background. What I'm finding is that the screen session terminates once the task is completed in Hudson.
Any ideas on why I can't launch a persistent screen session from a grand-parent script? Or any ideas on how to deal with this?
This is on OSX 10.6, with screen built from source (so it should work the same as linux I think).
If I run your test.sh, I get the error message
./test.sh: Zeile 2: myscreen.sh: Kommando nicht gefunden.
i.e. command not found. You'll have to write ./myscreen.sh, if the current directory is not on the path. (Is it for you? It should not.) The same is valid for the screen call.
Changing both files to
#!/bin/bash
./myscreen.sh
and
#!/bin/bash
screen -dm -S myscreen ./pingit.sh
I can start my screen without any problems.
I'm on Linux (OpenSUSE) with
$ screen --version
Screen version 4.00.03 (FAU) 23-Oct-06
here.
I don't know why I did not find the following references before, but these were the links that helped me solve the problem:
https://serverfault.com/questions/155851/run-gnu-screen-from-script
http://wiki.hudson-ci.org/display/HUDSON/Spawning+processes+from+build
There are 2 issues here - one of screen being persisted after being launched by a grand-parent process. The other that hudson terminates a session after it completes its task.
The screen problem is resolved by zombie'ing the process as follows:
screen -d -m -S myscreen && screen -S myscreen -X zombie qr && screen -S myscreen -X screen pingit.sh
The Hudson-CI problem turns out to be a bug that's easily resolved per the above link. The solution is to add BUILD_ID=something into the shell script. So if the test.sh script from above is actually the Hudson Build shell execute, then it would have to be changed to:
#!/bin/bash
BUILD_ID=dontkillthisprocess
myscreen.sh
Once both of these steps are implemented, things work fine.