I am developing an application on Linux CentOS server. I need to automatically after registration of each use server create a screen to run some codes in loop for user.
When I use bash script to create new screen, it can't open screen and run commands in that screen.
For example, I want to open an screen and I run a php file in that screen. I have created a bash script test.sh but when I run this using cron tab it doesn't work.
screen
php php.php
Please tell what can I do to solve this?
It's quite easy to do this and such a thread already exists.
screen -d -m yourcommand
Related
I have an issue about how to run screen through crontab, I made a script which check if a previous session is running and if not restart a screen.
cf screenshots below
crontab
restard_td.sh
When I run the script manually it's works fine, by cron, i can see my output "down, i will restart it " in my log file but no screen available and my script doesn't run.
Has someone got an idea ?
you can try checking the cron log, and use the screen full path.
I fixed it by using screen full path and python full path in my script.
like that
/usr/bin/screen -dmS team /usr/local/bin/python /home/admin/scripts/rattrapage/team.py
What's the best way to run this shell script where I need to create an output log at the same time run it in the background? The catch is, I need to input a couple of parameters then enter a password.
For example I execute the shell script like so:
-bash-4.3$ ./tst.sh param1 param2 >> tst.log
Password for user mas:
I need to pass in (2) parameters, then prompted for a password:
./tsh.sh <param1> <param2>
This will work, but I have to keep the session open and I want it so it goes to the background or something similar where it will continue to run if my connection to the host fails..
If you want to run something that will survive if your connection fails you should run it in a screen or tmux session. You can use those to create sessions that you can disconnect from and reconnect to, and many other really cool things once you start really getting into them.
So if you ssh in and then run screen you'll still be at a bash prompt, but if you run a command then press ^a^d you will detach from that session. Everything running inside screen will keep going, and you'll be able to reconnect with screen -x later. You can have many screen sessions at the same time too, use screen -ls to see which are running then you can use screen -x <id> to reconnect to a particular one.
How could a script wait for the login process to complete before running a command in shell script in Mac OS X?
I have tried wait and sleep commands, but that doesn't seem to stop the script running under the root that owns the login process.
I want the script run after the user logs in.
There are 2 easy(ier) options:
Create a Login Item. To see an example, click here.
Use launchd. You don't have to install anything. All you need to do is to create a configuration file to tell launchd what to do, and save it (with proper permissions) on a specific directory that's read by launchd.
This hopefully should be an easy question to answer. I am attempting to have mumble-ruby run automatically I have everything up and running except after running this simple script it runs but ends. In short:
Running this from terminal I get "Press enter to terminate script" and it works.
Running this via a cronjob runs the script but ends it and runs cli.disconnect (I assume).
I want the below script to run automatically via a cronjob at a specified time and not end until the server shuts down.
#!/usr/bin/env ruby
require 'mumble-ruby'
cli = Mumble::Client.new('IP Address', Port, 'MusicBot', 'Password')
cli.connect
sleep(1)
cli.join_channel(5)
stream = cli.stream_raw_audio('/tmp/mumble.fifo')
stream.volume = 2.7
print 'Press enter to terminate script';
gets
cli.disconnect
Assuming you are on a Unix/Linux system, you can run it in a screen session. (This is a Unix command, not a scripting function.)
If you don't know what screen is, it's basically a "detachable" terminal session. You can open a screen session, run this script, and then detach from that screen session. That detached session will stay alive even after you log off, leaving your script running. (You can re-attach to that screen session later if you want to shut it down manually.)
screen is pretty neat, and every developer on Unix/Linux should be aware of it.
How to do this without reading any docs:
open a terminal session on the server that will run the script
run screen - you will now be in a new shell prompt in a new screen session
run your script
type ctrl-a then d (without ctrl; the "d" is for "detach") to detach from the screen (but still leave it running)
Now you're back in your first shell. Your script is still alive in your screen session. You can disconnect and the screen session will keep on trucking.
Do you want to get back into that screen and shut the app down manually? Easy! Run screen -r (for "reattach"). To kill the screen session, just reattach and exit the shell.
You can have multiple screen sessions running concurrently, too. (If there is more than one screen running, you'll need to provide an argument to screen -r.)
Check out some screen docs!
Here's a screen howto. Search "gnu screen howto" for many more.
Lots of ways to skin this cat... :)
My thought was to take your script (call it foo) and remove the last 3 lines. In your /etc/rc.d/rc.local file (NOTE: this applies to Ubuntu and Fedora, not sure what you're running - but it has something similar) you'd add nohup /path_to_foo/foo 2>&1 > /dev/null& to the end of the file so that it runs in the background. You can also run that command right at a terminal if you just want to run it and have it running. You have to make sure that foo is made executable with chmod +x /path_to_foo/foo.
Use an infinite loop. Try:
while running do
sleep(3600)
end
You can use exit to terminate when you need to. This will run the loop once an hour so it doesnt eat up processing time. An infinite loop before your disconnect method will prevent it from being called until the server shuts down.
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.