Let's say I have launched tons of xterm in different queues. Now they all clutter my screen and I have lost which one is which. I want to stick the LSF job-ID and the requested machine memory resource into the xterm header bar. (I know I can do that at startup but lets assume I have all these xterms already sitting on my desktop and I want to stick the headers in after the fact)
I can use this to put text into the xterm header:
echo -e "\033]2; You can rent this place for a commercial. \007"
I am thinking of something like this:
get name out of uname -n
get machine resources for name out of bjobs <<== I don't know how to do that!!!
stick interesting stuff into header
run this in all my xterm.
Important stuff I want to get out of bjobs is :
machine size (so I know which size jobs I can launch in that xterm)
LSF job ID so that I know how to kill it.
Example how I launch an xterm:
qsub -q o_cpu_128G -J Gerts -P gf104 -n 8 -m "rel57" -R "span[hosts=1]" xterm -sb
Stuff I get out of bjobs
bjobs
JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME
8510290 ggottsc RUN o_cpu sc-xterm-02 8*sc-sim-21 Gerts Mar 5 14:44
7347117 ggottsc RUN o_cpu sc-xterm-02 8*l-sim-156 Gerts Mar 10 11:48
9081323 ggottsc RUN o_cpu sc-xterm-02 8*l-sim-237 Gerts Mar 11 10:21
Thanks,
Gert
I assume your 'qsub' command is a wrapper around bsub that submits the job interactively?
If so, for the jobId, you should be able to look at the environment variable $LSB_JOBID in your xterm to get it. So you can run something like:
echo -e "\033]2; Job ID: $LSB_JOBID \007"
To get the current terminal's job ID into the title.
For "machine size", I'm unclear what you mean. It sounds like you're interested in the memory of the machine, but you can get this from a lot of places. Based on the title of your question, I assume you want to get this from the name of the queue you submitted the job to (o_cpu_128G in your example). If that's the case, you should also find this available in the environment under the variable $LSB_QUEUE, so then you can display your queue name and your jobid in the xterm window title with:
echo -e "\033]2; Job ID: $LSB_JOBID Queue: $LSB_QUEUE \007"
Alternatively, you can try to determine the actual total/free memory on the host by parsing /proc/meminfo, or the output of a command like 'free -m'.
Related
I came across this shell script
bash# while true; do
vmtouch -m 10000000000 -l *head* & sleep 10m
kill %vmtouch
done
and wonder how does the kill %vmtouch portion work?
I normally pass a pid to kill a process but how does %vmtouch resolve to a pid?
I tried to run portions of script seperately but I got
-bash: kill: %vmtouch: no such job error.
%something is not a general shell script feature, but syntax used by the kill, fg and bg builtin commands to identify jobs. It searches the list of the shell's active jobs for the given string, and then signals that.
Here's man bash searching for /jobspec:
The character % introduces a job specification (jobspec).
Job number n may be referred to as %n. A job may also be referred to using a prefix of the name used to start it, or using a substring that appears in its command line. [...]
So if you do:
sleep 30 &
cat &
You can use things like %sleep or %sl to conveniently refer to the last one without having to find or remember its pid or job number.
You should look at the Job control section of the man bash page. The character % introduces a job specification (jobspec). Ideally when you have started this background job, you should have seen an entry in the terminal
[1] 25647
where 25647 is some random number I used. The line above means that the process id of the last backgrounded job (on a pipeline, the process id of the last process) is using job number as 1.
The way you are using the job spec is wrong in your case as it does not take process name of the background job. The last backgrounded is referred to as %1, so ideally your kill command should have been written as below, which is the same as writing kill 25647
vmtouch -m 10000000000 -l *head* & sleep 10m
kill %1
But that said, instead of relying the jobspec ids, you can access the process id of the background job which is stored in a special shell variable $! which you can use as
vmtouch -m whatever -l *head* & vmtouch_pid=$!
sleep 10m
kill "$vmtouch_pid"
See Job Control Basics from the GNU bash man page.
A script that keeps updating the log file. data like system time and date, users currently logged in etc for every interval of time say 5 minutes. THE SCRIPT MUST RUN EVEN AFTER THE TERMINAL HAS BEEN CLOSED.
Actually, no.
First of, you don't need sh:
$ ./newscript.sh &
This is enough. This will start a background process. But your terminal is still controlling it. To achieve the behavior you want, do this:
$ disown %1
This will disown the job with the jobspec 1 (which is like an id), which was the one you started beforehand. Now you can close the terminal.
Hurrah!! I would like to answer my question since i have got the solution.
For example, I'm running a script newscript.sh I want to run this in background and continue someother job in the terminal or i can close the terminal.
[yourname # username ~]$ sh newscript.sh &
and hit enter. You will get a PID and your job will be attached to the background.
To kill the same process, use the PID
For eg.,
kill 1205212
Thank you.
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.
Consider a script, "run.sh", to be sent to a cluster job queue via qsub,
qsub ./run.sh
My question is how do I get the number of the process -- the one that appears as ${PID} on the files *.o${PID} and *.e${PID} -- within the script run.sh?
Does qsub export it? On which name?
Well, apparently qsub man page does not have, but this page says that the variable $JOB_ID is created with the PID I was asking for.
I have a program that runs as a daemon, using the C command fork(). It creates a new instance that runs in the background. The main instance exists after that.
What would be the best option to check if the service is running? I'm considering:
Create a file with the process id of the program and check if it's running with a script.
Use ps | grep to find the program in the running proccess list.
Thanks.
I think it will be better to manage your process with supervisord, or other process control system.
Create a cron job that runs every few minutes (or whatever you're comfortable with) and does something like this:
/path/to/is_script_stopped.sh && /path/to/script.sh
Write is_script_stopped.sh using any of the methods that you suggest. If your script is stopped cron will evaluate your script, if not, it won't.
To the question, you gave in the headline:
This simple endless loop will restart yourProgram as soon as it fails:
#!/bin/bash
for ((;;))
do
yourProgram
done
If your program depends on a resource, which might fail, it would be wise to insert a short pause, to avoid, that it will catch all system resources when failing million times per second:
#!/bin/bash
for ((;;))
do
yourProgram
sleep 1
done
To the question from the body of your post:
What would be the best option to check if the service is running?
If your ps has a -C option (like the Linux ps) you would prefer that over a ps ax | grep combination.
ps -C yourProgram