I am running a bash script that, among other things, runs a java program that can be used via GUI or via command line (depending on a parameter).
splitstree --commandLineMode --commandFile comm.txt --version --verbose
EDIT:
When I run it via normal command line or via GUI, it works perfectly. If I echo this command into a file and $(cat file) it also works, and it works as well when I integrate it into a bash script and run the bash script.
If I qsub it to the cluster where I am doing the work, I get an error about a missing display:
java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed
an operation which requires it.
I tried to export DISPLAY=:0.0 within the bash script but the error didn't change.
EDIT 2:
If I pass the DISPLAY variable to the qsub command, the error goes away but the program terminates with an exit status of 1. Like:
qsub -v DISPLAY <job_file>
It also says Picked up _JAVA_OPTIONS: -Xmx4096M but performing unset on this variable didn't change the exit status (so probably is not harming the process).
Re-running the same command outside of qsub (that is: simply copy-paste the cmd into the shell) work perfectly again.
Any suggestion on how to make it so that the qsub command correctly passes the display information to the cluster node?
If you don't need the display run Java with -Djava.awt.headless=true property, as explained in Using Headless Mode in the Java SE Platform.
Alternatively, if your program can't run headless, you can try using Xvfb (X virtual framebuffer). It comes with xvfb-run command, take a look at Running without a Display wiki:
xvfb-run java MainClass
or by configuring DISPLAY environment variable:
sudo Xvfb :1 -screen 0 1024x768x24 </dev/null &
export DISPLAY=":1"
java MainClass
When in a headless environment, you need to use GraphicsEnvironment.isHeadless() in your code to avoid doing anything that requires AWT components. That means you can't do any input/output, of course.
Related
I'm calling a dtsx file in PowerShell(test.ps1) using below:
& $dtexec /f "$dtsx"
This works fine when I run the test.ps1 from command prompt in local machine but the same doesn't even trigger when test.ps1 is triggered from a java application.
please help.
I'd check if any other Powershell runs for You when started from Java, and only this particular one fails.
At some point I had similar problem. It turned out, that I was using Powershell module that required to 64bit powershell instance while I was running 32bit java process. This in turn was spawning 32bit Powershell process (You can check that with [Environment]::Is64BitProcess) that could not run what I was asking it to run.
I researched this question and all answers suggest visudo to add:
Defaults:user !requiretty
It does not work!
I have two Linux boxes (RedHat). I have a Java class which uses ProcessBuilder/Process to execute commands. The class runs under a system account.
On both boxes, I run
su other-user -c 'some-command'
and provide the password for other-user in an input stream to the Process object.
On one box, the command succeeds and on the other I get the error above.
The sudoers files on both machines did not have exclusions for requiretty ('Defaults requiretty' is set on both files).
I tried adding the exclusion as suggested by the answers I found. I tried both the system user running the process and 'other-user'...
Does not work.
What else can be the issue? Do I need to restart the system after adding the requiretty exceptoin(s)?
sudoers is for sudo rather than su so you should use sudo.
According to su manual:
-c, --command COMMAND
Specify a command that will be invoked by the shell using its -c.
The executed command will have no controlling terminal. This option cannot be used to execute interactive programs which need a controlling TTY.
you can use a TTY spawning if you are trying to avoid using sudo or you don't have a sudo privileges.
Just invoke one of the following codes before running the code which giving you the error you mentioned.
here are some examples of codes you can use, depends on the code or the system you are using:
python -c 'import pty; pty.spawn("/bin/sh")'
echo os.system('/bin/bash')
/bin/sh -i
perl —e 'exec "/bin/sh";'
perl: exec "/bin/sh";
ruby: exec "/bin/sh"
lua: os.execute('/bin/sh')
(From within IRB)
exec "/bin/sh"
(From within vi)
:!bash
(From within vi)
:set shell=/bin/bash:shell
(From within nmap)
!sh
the first three choices up are my common used ones, and I am trusting their results.
I am using them while pentesting.
I'm currently using an external editor of Matlab .m files, with a custom build system that calls Matlab from the command line to run the Matlab script (with the -nosplash and -nodesktop). However this creates two problems:
1) Matlab closes right after running the script: any windows or plots I call in the script are closed right after running the script, which obviously happens in a matter of seconds.
2) There is a slight delay every time I run the script because Matlab is effectively being started from scratch.
So I was wondering if would be possible to have Matlab running in the background, and just running the scripts whenever I want?
I'm running Linux 64bits, Matlab 2013a, and Sublime Text 3.
EDIT: I've testing the setup with a basic script:
a=5;
figure
plot(a);
EDIT2: I'm calling Matlab through a Sublime Text build system that runs:
matlab -nosplash -nodesktop <[script].m
There is no way to have Matlab running in the background and "just running the scripts whenever you want" without having an interactive session open somewhere.
Suppose that your system has a custom wrapper matlab-wrapper that is used to submit scripts in the background. You would call your script like this:
$ matlab-wrapper myscript.m
Likely, matlab-wrapper is doing something like this:
#!/bin/bash
/apps/matlab14a/bin/matlab -nodesktop -nosplash -r run\ "$1",exit
Or even more, submitting the above script to a scheduler via qsub or some other command.
The key would be modify the wrapper script to find the part where the Matlab binary is actually invoked. If your system allows, you could copy the wrapper script and modify it. (Either by simply removing the -r run\ "$1" text or something more complicated.) Then, you should be able to launch an interactive version of Matlab per the custom configuration on your system, and call your scripts from the Matlab command window.
The following process normally works for my startup scripts. However, when I introduce a command to execute a JAR file, it does not work. This script works while I am logged in. However, it does not work as a startup script.
In /etc/init.d I create a bash script (test.sh) with the following contents:
#!/bin/bash
pw=$(curl http://169.254.169.254/latest/meta-data/instance-id)
pwh=$(/usr/bin/java -jar PWH.jar $pw &)
echo $pwh > test.txt
Make script executable
In /etc/rc.local, I add the following line:
sh /etc/init.d/test.sh
Notes:
I make a reference to the script in /etc/rc.local, because this script needs to run last after all services have started.
Please do not ask me to change the process (i.e., create script in /etc/init.d/ and reference it from /etc/rc.local), because it works for my other startup scripts.
I have tried adding nohup in front of java command, and it still did not work.
Thanks
As written, there is insufficient information to say what is going wrong. There are too many possibilities to enumerate.
Try running those commands one at a time in an interactive shell. The java command is probably writing something to standard error, and that will give you some clues.
I've developed a Java console application that when start, open a console window and remain in foreground, i want to start that application in background .
Now i launch the application by this command line :
java -jar myapp.jar
Is there a way to achieve this behaviour ?
It's enough change the command line parameter or i need to do some change on my code ?
The answer is operating system dependent.
*nix: <your command> &
Windows: (opens a new console): start <your command>
Windows: (doesn't open a new console): start /b <your command>
If you are doing this in anything unix based then you can append & to the end which will spawn a new thread and keept it running in the background.
java -jar myapp.jar &
If you really just want it to run in the background, java -jar myapp.jar & will do the job. That way, it'll still die when the shell closes, but you can keep using your shell.
If you really want it run as a daemon, nohup java -jar myapp.jar & will do the job. That way, it'll continue to live when the shell closes.
If you want this to be reliable, you can prepare an init script or upstart job definition, or run it via Vixie cron(8) #reboot specifier to make it start at boot.
Given that you're using Windows, you might consider Java Service Wrapper. I have used it on a project in the past.