Is there any way to call mprirun inside FORTRAN program? I'm working on public linux cluster via ssh and the main idea is to automatically enqueue program after its execution is over.
I tried to write something like this at the end of the program:
CALL system('mpirun -np 16 -maxtime 100 TestNP')
But recieved this error:
sh: mpirun: command not found
Any ideas ?
The problem is the missing path prefix, so specifying an absolute path for mpirun should help. However there are several problems with your approach:
If every MPI process executes it, you would have too many instances running, so only one of the nodes (e.g. the master node) should execute it.
The original program won't be finished, until the one called via the system() call did not finish. So, if your queue is wall-clock limited, you don't gain anything at all.
Typically, tasks like this are done via shell-scripts. E.g. in Bash you would write something like:
while true; do
mpirun your_program
done
This would re-invoke mpirun continuously until not killed by you or the queuing system. (So be careful with it!)
Related
Is it possible to start a specific command of a Spring-Shell app and then return/exit the shell after the command is finished? Further is it possible to expose the exit code (System.exit) of the app to the operating system shell?
For my purpose i will take advantage of the plugin mechanism and the CLI-Annotations of Spring-Shell. But in general there is no human interaction with the app, instead a job scheduler (UC4) will start the app and check the exit code to generate an email in case of an exit code not equal to 0. On the other hand for manual tests by our customer, there is also the need of tab completion, usage help etc.
This behavior is already built-in (although we considered removing it, or at least make it optional). I see now that it is useful :)
Simply invoke the shell with your (sole) command and the shell will spin up, execute the command, and quit. Also, the return code of the shell already indicates whether there was an error or not (tried with an inexistant command for example). Of course, if your custom commands do not properly indicate an error (i.e. print an error message but perform a normal return) this will not work. You should throw an exception instead.
The behavior is back.
Run spring-shell with #my-script, like so:
java -jar my-app.jar #my-script
Where my-script is a file with your commands:
my-command1 arg1 arg2
my-command2 arg1 arg2
So I am trying to keep my Node server on a embedded computer running when it is out in the field. This lead me to leveraging inittab's respawn action. Here is the file I added to inittab:
node:5:respawn:node /path/to/node/files &
I know for a fact that when I startup this node application from command line, it does not get to the bottom of the main body and console.log "done" until a good 2-3 seconds after I issue the command.
So I feel like in that 2-3 second window the OS just keeps firing off respawns of the node app. I see in the error logs too in fact that the kernel ends up killing off a bunch of node processes because its running out of memory and stuff... plus I do get the 'node' process respawning too fast will suspend for 5 minutes message too.
I tried wrapping this in a script, dint work. I know I can use crontab but thats every minute... am I doing something wrong? or should I have a different approach all together?
Any and all advice is welcome!
TIA
Surely too late for you, but in case someone else finds such a problem: try removing the & from the command invocation.
What happens is that when the command goes to the background (thanks to the &), the parent (init) sees that it exited, and respawns it. Result: a storm of new instantations of your command.
Worse, you mention embedded, so I guess you are using busybox, whose init won't rate-limit the respawning - as would other implementations. So the respawning will only end when the system is out of memory.
inittab is overkill for this. I found out what I need is a process monitor. I found one that is lightweight and effective; it has some good reports of working great out in the field. http://en.wikipedia.org/wiki/Process_control_daemon
Using this would entail configuring this daemon to start and monitor your Node.js application for you.
That is a solution that works from the OS side.
Another way to do it is as follows. So if you are trying to keep Node.js running like I was, there are several modules written meant to keep other Node.js apps running. To mention a couple there are forever and respawn. I chose to use respawn.
This method entails starting one app written in Node.js that uses the respawn module to start and monitor the actual Node.js app you were interested in keeping running anyway.
Of course the downside of this is that if the Node.js engine (V8) goes down altogether then both your monitoring and monitored process will go down with it :-(. But its better than nothing!
PCD would be the ideal option. It would go down probably only if the OS goes down, and if the OS goes down then hope fully one has a watchdog in place to reboot the device/hardware.
Niko
We have an application that crashes at startup, especially under high load. Problem is, there's no way to tell apart the various instances of this process from one another, except the invocation command line itself.
Is there a way to use WinDBG, WER, etc. to extract the command lines of crashed processes? I know it's nested in the PEB somewhere. The goal would be to just have it dump the information so that we can see if the crashing processes have anything in common.
Thoughts?
Try ??#$peb->ProcessParameters->CommandLine
In WinDbg, !peb shows the Process Environment Block including the command line. Because the output is long, I recommend filtering it using .shell:
.shell -ci "!peb" find "CommandLine"
I'm looking for a way to run a program when locking the screen in Fedora 15 (linux). Basically I want to start running a motion detection program when the screen locks, or I manually hit Ctrl+Alt+L, but I don't know what commands are being run or where to alias my own intermediate step in. I assume it's:
gnome-screensaver-command --lock
but am not sure how to go about this. Anybody know how, or a direction to start looking in?
Edit, since link was in a comment:
This is done with dbus-monitor and described here.
The dbus system advertises screen locking; monitor for ActiveChanged on org.gnome.ScreenSaver. (see http://people.gnome.org/~mccann/gnome-screensaver/docs/gnome-screensaver.html )
e.g. (word-wrapped for clarity)
signal sender=:1.68 -> dest=(null destination)
serial=53 path=/org/gnome/ScreenSaver;
interface=org.gnome.ScreenSaver; member=ActiveChanged
boolean true
Unfortunately, this will require writing more code than just a shell script, I'm afraid; although I'd be curious if you could ask dbus to call your program as a handler for that signal, somehow; otherwise, I suppose you'd just start a daemon process and listen for that signal to be broadcast…
We use PHP gearman workers to run various tasks in parallel. Everything works just fine, and I have silly little shell script to spin them up when I want them. Being a programmer (and therefore lazy), I wanted to see if I could spin these up via an upstart script.
I figured out how to use the instance stanza, so I could start them with an instance number:
description "Async insert workers"
author "Mike Grunder"
env SCRIPT_PATH="/path/to/my/script"
instance $N
script
php $SCRIPT_PATH/worker.php
end script
And this works great, to start them like so:
sudo start async-worker N=1
sudo start async-worker N=2
The way I want to use these workers is to spin up some number of them (maybe one per core, etc), and I would like to do this on startup. To be clear, I don't need the upstart script to detect the number of cores. I'm happy to just say "do 8 instances", but that's why I want multiple running. Is there a way for me to use the "start on" clause in an upstart script to do this automatically?
For example, start instance 1, 2, 3, 4? Then have them exit on shutdown properly?
I suppose I could hook this into an init.d script, but I was wondering if upstart can handle something like this, or if anyone has figured out this issue.
Cheers guys!
What you need is a bootstrap task that runs on startup and iterates over all your worker jobs, starting each one.
#/etc/init/async-workers-all.conf
start on runlevel [2345]
task
env NUM_WORKERS=8
script
for i in `seq 1 $NUM_WORKERS`
do
start async-worker N=$i
done
end script
The key is to make this a task, which tells upstart to let the task run to completion before emitting any events for it. See http://upstart.ubuntu.com/cookbook/#task and http://upstart.ubuntu.com/cookbook/#instance