Security issues - Runtime().exec() on RMIServer

Hi.
I have a RMI system where the RMIClient calls the RMIServer to start a new program - notepad.exe - at the RMIServer.
RMIServer has a remote object that uses Runtime().exec() to start notepad.exe.
I have the following security policy file on the RMIServer:
grant {
permission java.net.SocketPermission "*:1024-65535",
"connect,accept";
permission java.net.SocketPermission "*:80", "connect";
permission java.io.FilePermission "C:\\WINNT\\system32", "read,write,execute";
I am getting the following exception:
java.security.AccessControlException: access denied (java.io.FilePermission <<ALL FILES>> execute)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkExec(Unknown Source)
at java.lang.Runtime.exec(Unknown Source)
at java.lang.Runtime.exec(Unknown Source)
at java.lang.Runtime.exec(Unknown Source)
at java.lang.Runtime.exec(Unknown Source)
at HelloImpl.executeLocalProgram(HelloImpl.java:32)
at HelloImpl.sayHello(HelloImpl.java:22)
at java.lang.reflect.Method.invoke(Native Method)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
I am not sure if I am missing any other security configuration. Please advise.
thankyou.
Denny

I think you may have the first path specified wrongly. Try making the first parameter "C:\\WINNT\\system32\\notepad.exe" see the JavaDoc for java.io.FilePermission for specifics.
Dave.

Similar Messages

Performance issue Runtime. exec("cp folder1 folder") in Linux,Weblogic.

Using Runtime. exec() copying files from folder1 to folder2 using cp command in Linux. It will take each file copy 2 sec if we use web logic 10.3 and jrocket. if we run in Linux without web logic it takes only 0.013 sec. why it takes more time to load cp command with web logic.
Environment
Weblogic 10.3
Linux 5.2
Jrocket 1.6

A 64 bit VM is not necessarily faster than a 32 bit one. I remember at least on suggestion that it could be slower.
Make sure you use the -server option.
As a guess IBM isn't necessarily a slouch when it comes to Java. It might simply be that their VM was faster. Could have used a different dom library as well.
Could be an environment problem of course.
Profiling the application and the machine as well might provide information.

Issue using Runtime.exec() in Vista

I've coded a simple method using Runtime.exec() to get the client MAC ID , and it worked alright on XP. Now my client want to switch to vista , and the method is not working. Here's my code
import java.io.*;
import java.util.regex.*;
public class GetMac
     public static String getMacAddress()
          String mac="";
          System.out.println("getMacAddress");
          try {
               RunTimeExecutor re=new RunTimeExecutor("ipconfig /all");
                mac=re.executeAndReturnMac();
                re.destroy();
          } catch (Exception e) {
               e.printStackTrace();
          return mac;
import java.io.IOException;
import java.io.InputStream;
* @author amal
public class RunTimeExecutor
          String cmd;
          Process proc;
           * @param cmd
          public RunTimeExecutor(String cmd)
                    this.cmd=cmd;
           * @return boolean
           * @throws WIException
          public String executeAndReturnMac() throws Exception
               System.out.println("run");
               String mac="";
                    if(cmd==null)
                              throw new Exception("No Commands");
                    try
                          final Runtime rt = Runtime.getRuntime();
                          proc = rt.exec(cmd);
                          final StreamGobbler errorGobbler = new StreamGobbler(proc.getErrorStream());
                          InputStream iis=proc.getInputStream();
                          final StreamGobbler outputGobbler = new StreamGobbler(iis);
                          errorGobbler.start();
                          outputGobbler.start();
                          int exit=proc.waitFor();
                          System.out.println("exitVAl "+exit);
                          if(exit==0)
                               mac=outputGobbler.MAC;
                          return (exit==0) ? mac :null;
                catch (IOException e)
                          e.printStackTrace();
                catch (InterruptedException e)
                          e.printStackTrace();
                catch(Exception e)
                     e.printStackTrace();
                return null;
          public void destroy()
                    if(proc!=null )
                              proc.destroy();
* @author amal
import java.io.*;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
* @author amal
public class StreamGobbler extends Thread
    InputStream is;
    OutputStream os;
    public String MAC;
    StreamGobbler(InputStream is)
        this(is,null);
    StreamGobbler(InputStream is,OutputStream redirectTo)
        this.is = is;
        this.os = redirectTo;
     * @see java.lang.Thread#run()
    public void run()
        try
            PrintWriter pw = null;
            if (os != null)
                pw = new PrintWriter(os);
            InputStreamReader isr = new InputStreamReader(is);
            int c=0;
            BufferedReader br = new BufferedReader(isr);
            String line=null;
System.out.println("Start Reading");
                 while ( (line = br.readLine()) != null)
                      System.out.println(line);
                     if (pw != null)
                         pw.println(line);
                     Pattern p = Pattern.compile(".*Physical Address.*: (.*)");
                        Matcher m = p.matcher(line);
                        if (m.matches())
                             MAC = m.group(1);
                             System.out.println("seting MAC to "+MAC);
                             break;
            if (pw != null)
                pw.flush();
        } catch (Exception e)
            e.printStackTrace();
}The inputStream of the process doesnt get printed at all , the loop condition in StreamGobbler 'while ( (line = br.readLine()) != null)
' is never true.
Also , in random cases i've seen the System.out.println("exitVAl "+exit); line executing before the System.out.println("Start Reading"); line , and i though proc.waitFor() would guarentee otherwise.

thx guys for ur replies . The issue was because of some browser security system ( or so they said . ).However i'm still puzzled about the 'waiting for the stream to finish' part .
paul.miner wrote:
{I think the process is allowed to end with output still in the >>buffers, ..so this would be expected. You should be waiting for >>your .streams to finish, since that's what you really >>care .about. .Also, .you need to add synchronization between your >>threads so you can accurately retrieve "MAC". Also, do not break out >>of the loop when you find what you're looking for, you should >>continue .reading until the end of the stream.Wasn't I suppose to be reading out of the stream to prevent an overflow?Also the break is done there are multiple lines like 'Physical address .....: xxxxxxxxxx ' in the output , and the macid is the first one.About the ProcessBuilder , I'll look into it . Thx for your advice.

About "kernel.exec-shield" and "because they will bring security issue" for linux ASE

In " ASE Quick Installation Guide for Linux", "kernel.exec-shield=0" and “kernel.randomaize-va-space=0” should be set.
But SuSE engineers say that “kernel.exec-shield=0”and “kernel.randomaize-va-space=0” will bring the OS security issue.
Customer want to know why ASE need the above parameters ?
Has anybody the idea for customer's question?

If the parameters are not set as documented, attempts to start additional engines beyond the first one will fail, generating stack traces.
ASE acts in many ways like it's own operating system, scheduling individual user connections (spids) to actively run (note that ASE was developed well before native threading was commonly available). Each spid has it's own stack information that gets swapped in when it is set to "running" state on the engine and swapped out when it yields the engine. The mechanics of this is not that different from the buffer overrun exploits described in the Red Hat document linked to by the
install guide, http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf
and the exec-shield mechanics definatately interfere ASE's operations when ASE is using multiple dataserver processes (engines) that swap spids around.
-bret

Runtime.exec() and security ?

Hello,
I have a program where a user can enter a binary path to openssl. The program then appends some hardcoded arguments to the openssl binary to do some crypto operation. I'm using Runtime.exec(String) to execute the command. For example:
*/usr/bin/openssl* smime -sign -certfile ....
Only the bold part of the command can be chosen by the user.
I'm a bit concerned about the security and I'm scared that a user could actually execute any command by injecting some shell code by entering for instance "verybadcommand #". I tried this and the execution fails which is good but are there any special things I should keep on mind ?
Thanks in advance,
Tex
Edited by: Tex-Twil on Feb 25, 2009 8:35 AM

Solved the problem. I was setting the DISPLAY variable when I launched the X application but not the XAUTHORITY variable. Once that was set the X application launched as expected.
- Bill

Issue using Runtime.exec() to export a DB

hi ,
i'm trying to write a piece of code to export an oracle DB using Runtime.exec(). I searched the forums and came up a with a piece of code , modified it a bit .The issue is the system sometimes hangs while executing the code , it's like the proc.waitFor() never returns. However the execution is error-free if using a command like 'shutdown' instead of 'exp' .
this is my main
public class DBExporter
           * @param args
          public static void main(String[] args)
                    try
                              StreamReaderThread outReaderThread = new StreamReaderThread();
                              StreamReaderThread errReaderThread = new StreamReaderThread();
                              //StreamReaderThread ww = new StreamReaderThread();
                              Runtime rt = Runtime.getRuntime();
                              outReaderThread.start();
                              errReaderThread.start();
                              String command = "exp beta/beta@frsp_dbS file=\"c:/shop.dmp\" full=\"N\" ";
                              //command = "shutdown -s";
                              Process proc = rt.exec(command);
                              outReaderThread.setInputStream(proc.getInputStream());
                              errReaderThread.setInputStream(proc.getErrorStream());
                              //ww.setOutputStream(proc.getOutputStream());
                              System.out.println(proc.waitFor());
                              proc.getInputStream().close();
                              proc.getErrorStream().close();
                              proc.getOutputStream().close();
                    catch (Exception e)
                              e.printStackTrace();
     }and this is the reader class
import java.io.BufferedWriter;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
*@deprecated
public class StreamReaderThread extends Thread
     private BufferedReader     br;
     private BufferedWriter     bw;
     private StringBuffer     sb;
     private String               newline;
     private String               line;
     public StreamReaderThread()
          br = null;
          sb = null;
          newline = null;
          line = null;
     public synchronized String getText()
          if( sb == null )
               return "";
          return sb.toString();
     private boolean     flag     = false;
     public synchronized void setInputStream( InputStream is )
          br = new BufferedReader(new InputStreamReader(is));
          flag = true;
     public synchronized void setOutputStream( OutputStream is )
               bw = new BufferedWriter(new OutputStreamWriter(is));
               flag = true;
     public synchronized void run()
          int i = 0;
          try
               while( !flag )
                    wait();
               flag = false;
               while( (line = br.readLine()) != null )
                    try
                         if( sb == null )
                              sb = new StringBuffer();
                              newline = System.getProperty("line.separator");
                         else
                              sb.append(newline);
                         sb.append(line);
                    catch( Exception e )
                         e.printStackTrace();
                    i++;
                    if( br == null )
                         break;
          catch( IOException ex )
               ex.printStackTrace();
          catch( InterruptedException ex )
               ex.printStackTrace();
}

Looks like a bug in StreamReaderThread. I can't see that it ever exits the wait() call since no one is calling notify or notify all.
Kaj

Runtime exec IOException issues

Hello,
I have spent two 10 hours days on this problem with countless search permutations and peering into everything from kernel source to java source. Unfortunately, I am not coming up with useful results.
Overview:
I have a very large java application (Apache solr) running on a server with 12GB memory. Without going into too much detail, this application at a point will use a Runtime exec call to fire off a bash shell script. Over time, however, I end up with an IOException "Cannot allocate memory." (More info and stack trace below.)
That application aside I have been able to reproduce this by varying the -Xms and -Xmx jvm parameters with confusing results using the simple program below:
//Use with various -Xms and -Xmx arguments to produce
//IOException on call to Runtime.exec()
import java.io.*;
public class DoRuntime {
   public static void main(String args[]) throws IOException {
      Runtime runtime = Runtime.getRuntime();
      long total = runtime.totalMemory();
      long max = runtime.maxMemory();
      long free = runtime.freeMemory();
      System.out.println("total: " + total);
      System.out.println("max: " + max);
      System.out.println("free: " + free);
      Process process = runtime.exec("/bin/ls");
      InputStream is = process.getInputStream();
      InputStreamReader isr = new InputStreamReader(is);
      BufferedReader br = new BufferedReader(isr);
      String line;
      while ((line = br.readLine()) != null) {
         System.out.println(line);
}Here are some sample runs:
RUN1
rwoodrum@util1wad:~/tmp$ java DoRuntime
total: 188743680
max: 954466304
free: 187759312
DoRuntime.class
DoRuntime.java
rwoodrum@util1wad:~/tmp$
RUN2
rwoodrum@util1wad:~/tmp$ java -Xms10g -Xmx10g DoRuntime
total: 10290069504
max: 10290069504
free: 10236381080
Exception in thread "main" java.io.IOException: java.io.IOException: Cannot allocate memory
        at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
        at java.lang.ProcessImpl.start(ProcessImpl.java:65)
        at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
        at java.lang.Runtime.exec(Runtime.java:591)
        at java.lang.Runtime.exec(Runtime.java:429)
        at java.lang.Runtime.exec(Runtime.java:326)
        at DoRuntime.main(DoRuntime.java:14)
rwoodrum@util1wad:~/tmp$
RUN3
rwoodrum@util1wad:~/tmp$ java -Xms10g -Xmx11g DoRuntime
total: 10290069504
max: 10498867200
free: 10236381080
DoRuntime.class
DoRuntime.java
rwoodrum@util1wad:~/tmp$-----
(FWIW, I get the same results replacing /bin/ls with something as lightweight as /bin/true.)
As can be seen in the above output of RUN2, I have set a fixed heap size of 10GB. The jvm seems content with that heap size, but when it goes to exec the child process it becomes rather unhappy. From this I would perhaps conclude that ultimately inside the call to forkAndExec (libjava.so) the call to fork() failed with an ENOMEM. (As a side note, an strace on the process doesn't actually ever show a fork, only a call to clone - which utilizes a fork eventually - more on clone below.)
The results of RUN3, however, seem to imply that the problem is within the jvm itself. In RUN3, I set the initial heap allocation to 10GB, as in RUN2, but I set the maximum at 11GB. One would think (or at least I would) that if the fork in RUN2 failed that it would certainly fail in the case of RUN3. It doesn't.
The manpage of clone indicates that the child process will "share parts of its execution context with the calling process". Indeed, if I'm reading it correctly, it indicates that the child process stack (among other things) is housed in the parent process address space.
Could it be that by setting this very large, fixed heap size as in RUN2, there is no room for the jvm to "maneuver" and properly handle the effort of the Runtime.exec? The fact that RUN3 is successful is what has made me think something like this, but I am by far an expert on how the jvm would handle that sort of thing.
In our production setup of this application, I adjusted the Xmx setting to be something larger than the Xms setting. This worked for a period of time, but eventually produced the same results. I suspect over time the heap simply increased toward the max and again the jvm couldn't do its thing when it came time to RunTime.exec. The fact that this happens on the trivial Runtime.exec program would seem to rule out a memory leak of the production application.
Ultimately something fishy is going on with memory, but with seemingly contradictory results, I am at a loss of where the problem lies.
If I have omittied any potentially relevant information, please let me know. Any thoughts are greatly appreciated.
Some basic system information:
rwoodrum@util1wad:~/tmp$ free
             total       used       free     shared    buffers     cached
Mem:      12304936   12200376     104560          0     337276    7082508
-/+ buffers/cache:    4780592    7524344
Swap:      2097144         32    2097112
rwoodrum@util1wad:~/tmp$ uname -a
Linux util1wad 2.6.18-4-amd64 #1 SMP Mon Mar 26 11:36:53 CEST 2007 x86_64 GNU/Linux
rwoodrum@util1wad:~/tmp$ java -version
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_10-b03, mixed mode)-ryan woodrum

I've continued to investigate this with my discoveries below. I've found some more interesting nuances, but am still not satisfied with the explanation of what is going on here. For time reasons, I've capitulated to a somewhat lame workaround.
The test run in the 1.6.0 jvm environment is somewhat revealing in that it confirms that the eventual call to fork (I'm kind of guessing it's the fork call here) is returning an ENOMEM. The 1.5.0 jvm was not returning the actual errno from the call in the JNI code. Checking out $linux_src/include/asm-generic/errno-base.h indeed enumerates ENOMEM to 12.
When I saw this, I started looking at the memory commit inside of /proc/meminfo to see what was going on when I would launch the jvm with the varying Xmx and Xms parameters. Somewhat unsurprisingly at this point, when I would run with large a large heap, the Committed_AS would skyrocket by a proportion roughly equal to the fixed heap size. (See here http://lwn.net/Articles/28345/ for an definition of Committed_AS and other /proc/meminfo fields.)
With the above information in hand, I wanted to confirm without a doubt that the kernel was the thorn in my side. So on a test system I started to play around with the vm_overcommit feature - see $linux_src/Documentation/vm/overcommit-accounting for definitions of modes 0,1, and 2). Sure enough, toying with these modes I was able to alter the behavior of launching the jvm. I switched from the default heuristic mode (0) to an "always overcommit" mode and it would launch and sucessfully fork and exec every time. No surprise there.
What IS surprising, however, is that if, under the default heuristic mode, I specify the jvm parameters differently it will sucessfully run and fork and exec the subprocess. It seems odd to me that at the OS level, specifying `java -Xms4g -Xmx4g` will cause the subprocess fork to fail but specifying `java -Xms4g -Xmx5g` will NOT cause the fork to fail. Running with the latter parameters shows the exact same Committed_AS spike. This all begs the question(s): What's the difference? With a min heap size set to 4g (or whatever) on the both jvm runs, how does a jvm parameter (especially one that allows MORE growth of the heap) impact this call to fork? One variable in the picture at this point that I'm unsure of is the strace call to clone(). I don't know what this could be doing to make things behave differently.
So as I noted, above, I have a relatively lame workaround. Blindly add more swap to increase the CommittedLimit inside the kernel. It'll never get used, it's a waste of space, and, perhaps most importantly, on principal it just rubs me the wrong way.
-ryan woodrum

Issue with Runtime.exec() or ProcessBuilder pb.start()

I am having problem with running a separate JVM process. The finished code must be able to start and forcibly stop the spawned process. The problem I am having is that the spawned process seems to hang. I have tried reading all output from the process with no luck. The java program opens a ServerSocket on a separate thread right away. However, when this is started through Runtime.exec() or ProcessBuilder the socket does not open until the first process is terminated. I have have been looking high and low for an answer that will fix this. I could write this all as a multithreaded application, however I would really like to isolate the second process in terms of the JVM settings. I would like to be able to monitor this process directly and indirectly for failure or early termination and restart it automatically. Other Java program I run with this method experience the same problem--a hang at a variable point in execution that is not relieved until the originating process ends.
        try {
            ProcessBuilder pb = new ProcessBuilder("\"C:\\Program Files\\Java\\jre6\\bin\\java.exe\" -jar -server \"PATHTOJAR\"");
            Process p = pb.start();
            java.io.InputStream is = p.getInputStream();
            while(running) System.out.print(is.read());
        catch (java.io.IOException ioe) { ioe.printStackTrace(); }

The finished code must be able to start and forcibly stop the spawned process.Process.destroy().
I have tried reading all output from the process with no luck.No you haven't - see below.
The java program opens a ServerSocket on a separate thread right away. However, when this is started through Runtime.exec() or ProcessBuilder the socket does not open until the first process is terminated.Which of these programs is which?
ProcessBuilder pb = new ProcessBuilder("\"C:\\Program Files\\Java\\jre6\\bin\\java.exe\" -jar -server \"PATHTOJAR\"");That should be
ProcessBuilder pb = new ProcessBuilder("C:\\Program Files\\Java\\jre6\\bin\\java.exe", "-jar", "PATHTOJAR", "-server");
java.io.InputStream is = p.getInputStream();
while(running) System.out.print(is.read());(a) call ProcessBuilder.redirectErrorStream(true);
(b) the loop must stop when is.read() returns -1, and you shouldn't print that value.

Problem with method Runtime.exec()

i wrote this simple line, in a servlet:
Runtime.getRuntime().exec(myCommand);
if i run this servlet in the OC4j included whith jdeveloper all works well...but if i run the same servlet in the Application server, the command is not executed...why????
is it a security issue?
please help me..

Stefano, can you take a look at the application server log files to see if there is any related information that tells what was happening? What is better, can you try catching the standout and standerr of your command as what is done in the following message?
Re: javac not found on UNIX AIX runnig Oracle AS 9.0.4
Please tell me if you have any new findings then.

Runtime#exec() from within a J2EE application

I've got a batch processing task running on a timer as part of my J2EE application on WebLogic 8.1 and I'm experiencing problems with invoking Runtime#exec().
To be more accurate, this is what I'm trying to do:
* Moves a file in the filesystem using native shell commands.
* @param src The file to move.
* @param dst The destination file.
public void move(String src, String dst) {
Runtime runtime = Runtime.getRuntime();
Process p = runtime.exec(new String[] { "mv", "-f", src, dst });
}Now, this piece of code works perfectly when run manually ("java Move foo.txt bar.txt") but when it's run within the J2EE application -- as the same user as in the manual case -- the file's won't get moved anywhere.
I suppose it's a permission/policy issue. If that's the case, how should I edit the policy file?
I already tried to add the following lines to weblogic.policy:
grant codeBase "file:${user.domain}/myServer/.internal/-" {
permission java.security.AllPermission;
grant codeBase "file:${user.domain}/myServer/.wlnotdelete/-" {
permission java.security.AllPermission;
};...but that didn't seem to help at all.

Ok. I managed to solve this one by myself. The solution was to read the "stdout" and "stderr" streams from the process.
Any idea why reading the streams helped?

Error in opening a file with name in chinese characters with Runtime.exec

The issue at hand is when I try to open a file with file name containing chinese characters in a localized environment in Windows through the following java code:
Runtime.exec("rundll32 SHELL32.DLL,ShellExec_RunDLL {File_With_FileName_containing_Chinese_character}");
the following error is thrown by windows.
Cannot open file "C:\??.txt".
with the exception
java.io.IOException: CreateProcess: [Ljava.lang.String;@f5da06 error=2
        at java.lang.Win32Process.create(Native Method)
        at java.lang.Win32Process.<init>(Win32Process.java:66)
        at java.lang.Runtime.execInternal(Native Method)
        at java.lang.Runtime.exec(Runtime.java:566)
        at java.lang.Runtime.exec(Runtime.java:428)
        at java.lang.Runtime.exec(Runtime.java:364)
        at java.lang.Runtime.exec(Runtime.java:326)
        at Launcher.main(Launcher.java:26)
When I try to use the same command (shown below) from the Windows Run command, the file opens sucessfully
rundll32 SHELL32.DLL,ShellExec_RunDLL {File_With_FileName_containing_Chinese_character}
Please suggest.
Thanks in advance

This may be a file association problem. To solve that:
In Windows 7:
1. Right-click the file,
2. Select "Open With"
select [Your Program Here]
3. Check always use this program.
In Windows XP:
1. Locate the file as you have described above
2. Right click the file
3. Select Open with from the pop-up menu
4. Click Choose default program…
5. Select Excel in the Recommended Programs box
6. Check Always use the selected program to open this kind of file
7. Click on OK.
1. Make Excel not available from Office 2007 listed under Programs and Features in Control Panel.
2. Take a registry backup using the steps given here
3. In the registry editor window expand HKEY_CLASSES_ROOT and navigate to .xls right and delete it.
4. Exit Registry Editor
5. Undo Step 1 to make Excel available.
6. Restart the computer and verify it the issue is fixed.
If this answer solves your problem, please check Mark as Answered. If this answer helps, please click the Vote as Helpful button. Cheers, Shane Devenshire

Using runtime.exec to zip some files

Hi,
I am using runtime.exec to try to automatically zip a bunch of files on a server. However, it does not seem to be working.
Before I execute the command, I save the zip command in a string. I then print the string to a log file, and then execute the runtime zip command. But nothing happens.
Yet, when I copy the string from the log, and paste it in a terminal, it properly creates the zip files. So, I know I have the correct command string, it just does not seem to be working within the java application. Also, the command string uses fully qualified directories, so it is not a directory issue.
I am using ubuntu linux.
Any ideas?
-Adam

adamSpline wrote:
Hi,
I am using runtime.exec to try to automatically zip a bunch of files on a server. However, it does not seem to be working.
Before I execute the command, I save the zip command in a string. I then print the string to a log file, and then execute the runtime zip command. But nothing happens. Within Runtime.exec() any command does not run in a shell and I bet you use wild cards and/or other commands to be interpreted by a shell which will not be interpreted since there is no shell. And, since you don't mention error messages or the return code, I will also bet you don't process the Process stdout , stderr and the return code properly.
It looks to me like you have fallen for at least two for the traps in [http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html|http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html].
>
Yet, when I copy the string from the log, and paste it in a terminal, it properly creates the zip files. So, I know I have the correct command string, it just does not seem to be working within the java application. Also, the command string uses fully qualified directories, so it is not a directory issue.
I am using ubuntu linux.
Any ideas?I agree with 'masijade' - use the built in Java classes.
>
-Adam

Runtime.exec() hangs on solaris 10, deadlock in soft_delete_session ?

Hi,
In my application sometimes Runtime.exec calls hangs for ever.
The pstack of java process is at the end of the post. It seems like there is a deadlock in soft_delete_session.
Does anyone know of any java/os patch we can apply to fix this issue?
I will really appreciate any tips to get over this issue.
# uname -a
SunOS thor256 5.10 Generic_120011-14 sun4u sparc SUNW,Sun-Fire-V245
# /opt/VRTSjre/jre1.5/bin/java -version
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode)
The trace is as follows:
0xff340408 __lwp_park + 0x10
0xff339068 mutex_lock_internal + 0x5d0
0xfb08a2ec soft_delete_session + 0xf0
0xfb089f90 soft_delete_all_sessions + 0x4c
0xfb084348 finalize_common + 0x70
0xfb0844d8 softtoken_fini + 0x44
0xfb0d8d48 _fini + 0x4
0xff3c00d0 call_fini + 0xc8
0xff3ca614 remove_hdl + 0xab8
0xff3c4d54 dlclose_intn + 0x98
0xff3c4e68 dlclose + 0x5c
0xfb3a2b3c pkcs11_slottable_delete + 0x138
0xfb39d664 pkcs11_fini + 0x4c
0xff2c0ea0 postforkchild_handler + 0x30
0xff332c20 fork + 0x140
0xfe8f8df4 Java_java_lang_UNIXProcess_forkAndExec + 0x7d4
0xf9226020 0xf9226020 * java.lang.UNIXProcess.forkAndExec(byte[], byte[], int, byte[], int, byte[], boolean, java.io.FileDescriptor, java.io.FileDescriptor, java.io.FileDescriptor) bci:0 (Compiled frame; information may be imprecise)
0xf92216c4 0xf92216c4 * java.lang.UNIXProcess.(byte[], byte[], int, byte[], int, byte[], boolean) bci:62 line:53 (Compiled frame)
0xf90fa6b8 0xf90fa6b8 * java.lang.ProcessImpl.start(java.lang.String[], java.util.Map, java.lang.String, boolean) bci:182 line:65 (Compiled frame)
0xf90fbe0c 0xf90fbe0c * java.lang.ProcessBuilder.start() bci:112 line:451 (Compiled frame)
0xf921842c 0xf921842c * java.lang.Runtime.exec(java.lang.String[], java.lang.String[], java.io.File) bci:16 line:591 (Compiled frame)
0xf9005874 * java.lang.Runtime.exec(java.lang.String[]) bci:4 line:464 (Interpreted frame)
0xf9005874 * TestExec.run() bci:26 line:22 (Interpreted frame)
0xf9005c2c * java.lang.Thread.run() bci:11 line:595 (Interpreted frame)
0xf9000218
0xfecdca88 void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*) + 0x5b8
0xfecf4310 void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,symbolHandle,symbolHandle ,Thread*) + 0x18c
0xfecf416c void thread_entry(JavaThread*,Thread*) + 0x12c
0xfecf3ff0 void JavaThread::run() + 0x1f4
0xff02fb30 void*_start(void*) + 0x200
0xff340368 lwpstart

Found this information about this problem:
Bug: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6276483
Info for patch 127111-11: http://sunsolve.sun.com/search/document.do?assetkey=1-21-127111-11-1
Download page: http://sunsolve.sun.com/show.do?target=patches/zos-s10

Runtime.exec() fails

Hi,
I have a process with many executables which work together to copy a script to another machine, execute it and get back the results. I am using Runtime.exec to execute the process. The files are stored in the directory "/opt/mx/myDir".
Below are two scenarios. One works and the other doesnt.
1. Working case.
#cd /opt/mx/myDir
#java myJavaClass.
2. Failing case.
#java myJavaClass.
The issue is that myJavaClass is part of another project and hence I cannot "cd" to /opt/mx/myDir. So it executes at some directory and fails.
Hence I tried ProcessBuilder.directory(file) - This fails too.
I have no logs or anything as the other process is not mine.
Any help on debugging this will be great.
Thanks.

Apologies if this is too obvious, but is your command
#java myJavaClass.
or
java myJavaClass
The trailing period is wrong.

Use of Runtime.exec

I know that there are security concerns with making a call to the java.lang.Runtime's
exec method, but are there any performance concerns? When an exec call is made
by an object within the application server does the forking of a new process to
execute the command cause a process equivalent in size to the application server
to be generated? Our application server process is quite large, so this would
be an expensive operation.

The OS-level semantics of Runtime.exec are tied to JVM implementation (that's why
it doesn't work on most releases of the MacOS for example)...
Runtime.exec has a lot of not-so-intuitive handholding associated with it. For
example, did you know that on most flavors of Windows JVMs, you have to read out
of the STDOUT and STDERR streams, or the process you invoked will hang when their
buffer fills up? JavaWorld ran an article a while back with all the details on
this-- you can write a stream gobbler to suck up anything and send it to /dev/null
to avoid problems.
"Ash Beitz" <[email protected]> wrote:
>
I know that there are security concerns with making a call to the java.lang.Runtime's
exec method, but are there any performance concerns? When an exec call
is made
by an object within the application server does the forking of a new
process to
execute the command cause a process equivalent in size to the application
server
to be generated? Our application server process is quite large, so this
would
be an expensive operation.

Security issues - Runtime().exec() on RMIServer

Similar Messages

Maybe you are looking for