I am running a MATLAB script at a cluster, having used the command
matlab -nodisplay <LocalVariation.m
I can now see that it is not going to finish within the wall time I have put. Is there any way that after I have ssh'ed to the node, that I can open up the running MATLAB instance, and stop it within the program, such that I get access to the variables it has produced so far?
It seems Matlab does not allow that unless you explicitly include it beforehand in your Matlab script. See this answer for instance.
Also it is always good to make your script 'checkpointable' so that you are able to restart easily from where the script was stopped.
Finally, a word about Octave, which has the option to create a dump of the variables automatically upon wrongful termination of the program.
Assuming you are using the SLURM workload manager you can try the following.
First open an interactive bash session using srun --pty bash -i. If you check your job queue using,squeue -u <username> you should find a bash session:
Now run your Matlab code with a breakpoint where you wish to stop execution. For example, a file runTestJob.m could look something like:
function runTestJob
A = rand(5);
B = randn(5);
keyboard; % add breakpoint
end
Now run code,
srun matlab -nodisplay -singleCompThread -r "runTestJob;quit"
This should give you a Matlab access directly in the terminal, so that you can use Matlab just like you would use it in the command window:
After you are done, make sure to close the interactive session and free up resources:
scancel <JOBID>
Hope that helps!
Related
As part of a bigger script I'm using print -z ls to have zsh's input buffer show the ls command. This requires me to manually press enter to actually execute the command. Is there a way to have ZSH execute the command?
To clarify, the objective is to have a command run, keep it in history, and in case another command is running it shouldn't run in parallel or something like that.
The solution I've found is:
python -c "import fcntl, sys, termios; fcntl.ioctl(sys.stdin, termios.TIOCSTI, '\n');
I'm not sure why, but sometimes you might need to repeat the command 2 times for the actual command to be executed. In my case this is happening because I send a process to the background, although this still doesn't make much sense because that process is sending a signal back to the original shell (triggering a trap) which actually calls this code.
In case anyone is interested, this was my goal:
https://gist.github.com/alexmipego/89c59a5e3abe34faeaee0b07b23b56eb
I have the following code written in a script anmed test.csh to start a GUI based application in foreground in Solaris Unix. When I run the script and want to kill the GUI process using Keyboard Ctrl + C, the process is not getting terminated. If I open the GUI application directly from the terminal, I am able to kill the process using Ctrl + C. Can someone help me understand why am I not able to kill the process invoked from a script?
#! /usr/bin/csh
# some script to set env variables
# GUI Process
cast
Then I execute the script using the following command. I am not able to terminate the vcast process using Ctrl + C command.
source test.csh
If it is being launched into its own thread then the hangup request may not get to the application. You could add a signal handler to cascade the hangup request or look at the process table to see what the process id is for the app and then kill it. This could also be scripted very easily.
You should better execute the script directly, instead of sourcing it.
1) first add #!/bin/csh at the beginning of your script,
2) set it as executable :
$ chmod u+x test.csh
3) execute it directly:
$ ./test.csh
you should be able to kill it. Anyway, consider that the problem may be related to some executable code that you are running within your script. Consider to try to debug your script by copy-pasting line after line in a terminal until you reach the point where it lags.
Another possible annoying issue can be an infinite while loop. Check for this kind of error too. Maybe you have a while loop that never gets the breaking point.
Regards
In Windows you can use the following command in Matlab to start a new instance of MATLAB which will run in the background (i.e. you can keep executing commands in your first version of MATLAB).
system('matlab &')
An analogous call in OSX,
system([matlabroot '/bin/matlab &'])
however results in the display of the splash image, then nothing. If I take out the ampersand, the new instance opens as expected. Unfortunately, this won't work for me, I really need to be able to control the first instance of MATLAB while the second is running.
Does anyone know why this discrepancy between the operating systems exists? By the way, I'm using OSX 10.7, Windows 7 64 bit, and MATLAB R2012a on Mac and R2012b on PC.
As some background, I'm trying to write a generic tester for an interactive command line interface that uses the input() function extensively.
Edit: I should have mentioned that the command
/Applications/MATLAB_R2012a.app/bin/matlab &
works as expected from the OSX terminal. In other words, a new instance of MATLAB opens and new commands can be entered into the terminal. So this problem seems to be specific to the system() function in OSX matlab.
Also, I tried adding that command to a bash script and calling the script from matlab, but had the same problem that I did with putting the command into the system() function.
Thanks
This is a long shot, but it might be happening because when you invoke the new instance of Matlab from Matlab with the system() command on Unix or OS X, the matlab_helper process forks and runs a shell process to run the new application. If you omit the ampersand, the shell blocks and waits for the program to finish, and system() waits for it, so the first Matlab locks up. And (here's the speculation part) if you add the ampersand, Matlab launches in the background, and then the forked shell exits, which then causes the new Matlab process to exit because its parent process (the shell) has exited. (Windows doesn't have the same parent/child process relationships, process launch mechanism, or shells, which would explain the different behavior.)
You could try prefixing the command with nohup, which protects processes from getting killed by SIGHUP, which might be what's happening here to your second Matlab process.
system(['nohup ' matlabroot '/bin/matlab &'])
You could also try using the OS X open command to launch a new independent instance. Something like this. You may need to fiddle with the options and path, but -n should be what gives you a new instance. It should be pointing at /Applications/MATLAB_R2012a.app; I'm assuming that's what matlabroot is returning on OS X.
system(['open -na ' matlabroot])
You could also try running it from the Java process-launching features from within Matlab instead of with system(). Runtime.exec() doesn't block like system() does, and there may be other quirks to system(), like the matlab_helper architecture. Try launching it with java.lang.Runtime from Matlab.
jrt = java.lang.Runtime.getRuntime();
newMatlabProcess = jrt.exec([matlabroot '/bin/matlab']);
You can try the other command line variants above using this mechanism too, and you may need to redirect stdout to /dev/null, since the new processes input and output are buffered in to that newMatlabProcess object.
You can use applescript to do this. I do something like this:
! osascript -e "tell application \"Terminal\" to do script \"cd `pwd`;matlab -nojvm -nosplash -r 'why'\""
This example opens a new Matlab instance, in the current directory, and runs the command "why". You can remove the "-nojvm" if you need java in your background Matlab process
I'm interested in finding out how I'm able to do the following, but automatically.
Right now I have a bash script that looks something like this:
#!/bin/sh
sass --watch htdocs/css/scss:htdocs/css --debug-info
Now, because I want to be able to run other command-line tasks at the same time as this script is running, I could just run it inside a new window, but I prefer to have it run as a background process, which I achieve by:
Hitting [ctrl] + [Z]
Running bg
Which lets me continue to use the command-line, while also seeing the output from the sass command.
I'm also able to use jobs to see what's running, and finally, fg to bring the background script to the forefront, and use [ctrl] + [c] to cancel out of it.
All of which is fine, but it's a bit long-winded - is there any way that I can edit the bash script so it will automatically run in the background, similar to what I've described above?
Thank you
$ ./script &
^--- run script in background from the get-go
An alternative to this , which I found useful is to write a function
Foo(){
Do stuff
}
and call the function and send it to the background
Foo &
All within the script, so you don't have to do
script.sh &
Instead, just invoking the script will send it to the background.
I have a series of 7 processes required to run a complex web app that I develop on. I typically start these processes manually like this:
job &>/tmp/term.tail &
term.tail is a fifo pipe I leave tail running on to see the output of these processes when I need to.
I'd like to find away to start up all the processes within my current shell, but a typical script (shell or ruby) runs w\in it's own shell. Are there any work arounds?
I'm using zsh in iTerm2 on OSX.
You can run commands in the current shell with:
source scriptfile
or
. scriptfile
A side note, your processes will block if they generate much output and there isn't something reading from the pipe (i.e. if the tail dies).