Hi Curtis, list,
I have had success using xvfb -- and specifically xvfb-run called from a script xvfb-run-safe by Charles Duffy via StackOverFlow, quote;
"...let's write our own code to find a free display number, instead of assuming that xvfb-run -a will work reliably:
#!/bin/bash
# allow settings to be updated via environment
: "${xvfb_lockdir:=$HOME/.xvfb-locks}"
: "${xvfb_display_min:=99}"
: "${xvfb_display_max:=599}"
# assuming only one user will use this, let's put the locks in our own home directory
# avoids vulnerability to symlink attacks.
mkdir -p -- "$xvfb_lockdir" || exit
i=$xvfb_display_min # minimum display number
while (( i < xvfb_display_max )); do
if [ -f "/tmp/.X$i-lock" ]; then # still avoid an obvious open display
(( ++i )); continue
fi
exec 5>"$xvfb_lockdir/$i" || continue # open a lockfile
if flock -x -n 5; then # try to lock it
exec xvfb-run --server-num="$i" "$@" || exit # if locked, run xvfb-run
fi
(( i++ ))
done
If you save this script as xvfb-run-safe, you can then invoke:
xvfb-run-safe python script.py
...and not worry about race conditions so long as no other users on your system are also running xvfb. " </quote>
Link:
http://stackoverflow.com/questions/30332137/xvfb-run-unreliable-when-multiple-instances-invoked-in-parallelIn my case (on Debian linux VMs), the calls look like:
xvfb-run-safe ~/ImageJ/jre/bin/java -Xmx2048m -jar ~/ImageJ/ij.jar -ijpath ~/ImageJ -batch mymacro.ijm arg1:arg2 > /dev/null &
xvfb-run-safe ~/ImageJ/jre/bin/java -Xmx2048m -jar ~/ImageJ/ij.jar -ijpath ~/ImageJ -batch mymacro.ijm arg3:arg4 > /dev/null &
xvfb-run-safe ~/ImageJ/jre/bin/java -Xmx2048m -jar ~/ImageJ/ij.jar -ijpath ~/ImageJ -batch mymacro.ijm arg5:arg6 > /dev/null &
....
The redirect to /dev/null is required because the macro outputs intermediate Results tables as well as my logging statements written with print(), so output to stdout is too massive and hard to use.
I thought this might be useful to someone down the road.
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html
Locked
