My question consists of several things I don't understand about the use of "cmd.exe", "/c" when executing sub-processes from Java in Windows. Basically, I couldn't find a good explanation about when and why they're needed.
My specific problems: I have a small framework for sub-processes execution. One use is a Java application which "manages" several other JVMs created by ProcessBuilders. One of the key requirements is that when a sub-process is stuck, or the hosting application is terminating, it must be able to kill the sub-processes.
The problem is, on one hand, doing this:
new ProcessBuilder("java", "...").start();
Causes this:
Could not find or load main class ...
As if the system variables or directory are different (which they're not). On the other hand, wrapping it in a cmd.exe like this:
new ProcessBuilder("cmd.exe", "/c", "java", "...").start();
WORKS, but creates another cmd.exe process, which has a side effect: the child JVM is now a sub-sub-process, and process.destroy(); doesn't kill it (a known bug in the Windows JRE as I found).
This specific problem was handled on a different level, since all those applications are ours and we know their PIDs. But it's an example how cmd.exe makes everything work differently (or prevent the JVM from working at all). So I'd like to know what exactly happens there.
Here the framework itself comes into the picture as well. It's also going to be used by our testing platform. I'd like to provide an API which allows wrapping the command with a cmd.exe /c by a parameter. But, what exactly is the meaning of that parameter? How do the users decide if they want a cmd.exe wrapping?
AND a bonus I'd appreciate: is any of this relevant in other OS? Does it have some kind of an equivalent, say, in Linux?
Came across it again and found the problem, and some additional insights.
#HarryJohnston - good point, according to the javadoc the sub-process inherits the environment from both ProcessBuilder and Runtime.getRuntime.exec(...) APIs so it's not the issue (and java.exe is in fact found so PATH is obviously available).
But it seems certain command line features are lost. Among others it's this kind of %VARIABLE% usage in command line - they're not interpreted unless the command starts with cmd.exe /c.
In this case of class not found (it could also cause NoClassDefFoundError), I had several variables used in the classpath (perhaps I should have posted the entire command, but it's kinda long). When I replaced them with the literary paths, everything worked.
Basically:
java -cp %classpath% Main - bad
cmd.exe /c java -cp %classpath% Main - good
java -cp D:\proj\bin Main - good
So, on the general question of how's the behavior different with cmd.exe:
Variable references like this: %VARIABLE% are only interpreted by cmd.exe.
With cmd.exe you don't really need to split the command into String array of parameters, you can use one long String (array of "cmd.exe", "/c", "the rest...").
The sub-process will be cmd.exe and not the actual executable, so process.destroy() won't kill it. This might be a bug fixed in later versions (I used Java 7 and 8, Windows 7 and Server 2012).
File associations only work with cmd.exe, so you can't "execute" a file that is not a program or script ("CreateProcess error=193, %1 is not a valid Win32 application"). Calling executables defined in PATH does work.
start and call are only available under cmd.exe.
Command level errors behave differently as well: With cmd.exe the error will just be in the output stream, whereas without it the API throws an exception, which might also have a slightly different description.
For example:
nothing will cause java.io.IOException: CreateProcess error=2, The system cannot find the file specified
cmd.exe /c nothing will return output: 'nothing' is not recognized as an internal or external command, operable program or batch file, and a return value of 1 (the only indication something went wrong).
On the deeper question of why, and is this the full list of differences, I still don't really know. Looks like the JVM has its way of running commands, which you can "wrap" with cmd.exe for additional features and protection.
Another interesting fact is when you run a Batch, it's actually run under a cmd.exe (with all its features). From my tests it seems process.destroy() can only kill it if it's not waiting for anything external (if stuck on pause for example), with or without additional cmd.exe /c wrapping, but not if it runs a sub-process - which is consistent with the cmd.exe limitation mentioned in point 3.
Related
I have come across a problem while working with Process and ProcessBuilder in Java.
I have a line of code looking like this :
Process process = new ProcessBuilder("des.exe", String... params);
It works fine on my personal computer, but not on my testing server and I can't figure out why.
The ErrorStream give me this:
des.exe: MZ����#���: not found
des.exe: Syntax error: "(" unexpected
Both computers are on Ubuntu 16.04.4 LTS with java 1.8.
Any idea where it might come from?
The most likely reason for the difference is that the file format of windows executables is not registered with the binfmt_misc handler in the kernel, which allows the kernel to execute various programs through helpers transparently. The error Syntax error: "(" unexpected typically means that the file got handed off to /bin/sh, instead of to wine.
So, check if the binfmt_misc file system is mounted (most modern linuxes do this automatically):
grep binfmt_misc /proc/self/mountinfo
should return some entries (might be autofs, might be binfmt_misc depends on the distro).
if it isn't then mount it:
sudo mount -t binfmt_misc binfmt_misc /proc/sys/fs/binfmt_misc
you can tell what's registered by looking at the content of this directory. To register for running dos executables with wine you need to register it:
echo ':DOSWin:M::MZ::/usr/bin/wine:' | sudo tee /proc/sys/fs/binfmt_misc/register
Once registered, executing the binary should happen transparently, and it should succeed through the ProcessBuilder.
Configuring this for the server at boot time is left as an exercise to the user.
If you want to skip this entire mess, then you can change the execution from des.exe to wine with the first argument of des.exe.
I am trying to execute netstat command from java using runtime execution, but it throwing below IOException.
It works fine for other commands, even the synonym command onetstat is working fine. I am trying understand why netstat alone is failing and how to make it work. any help is appreciated.
java.io.IOException: Cannot run program "netstat": netstat: not found
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1059)
at java.lang.Runtime.exec(Runtime.java:629)
at java.lang.Runtime.exec(Runtime.java:462)
at java.lang.Runtime.exec(Runtime.java:359)
at com.ca.RunCmd.executeCommand(RunCmd.java:30)
at com.ca.RunCmd.main(RunCmd.java:18)
Caused by: java.io.IOException: netstat: not found
at java.lang.UNIXProcess.fullPath(UNIXProcess.java:306)
To really understand what's going on here, you'll need to hunt down the actual executable, whether netstat or onetstat.
If netstat is aliased to onetstat in the shell - depending on which shell you're running, the "whence" or "alias" command will tell you. A simple solution might be to run the command via the shell (/bin/sh -c netstat) rather than running netstat directly.
Another possibility is that these commands are what's known as an "external link"...a way for a UNIX Service pathname to point to a conventional executable in a z/OS dataset. If this is the case, then you very well might have the netstat/onetstat in your path and otherwise correct, but you might not have the correct STEPLIB or LNKLST concatenation. When the system exec's the target (netstat/onetstat), it doesn't find the externally-linked program, and you get the "not found".
All sorts of things can go wrong here, especially when external links are involved. There can be system (APF) authorization issues, missing modules in your STEPLIB/LNKLST, not enough memory to load the program, etc etc etc. Unfortunately UNIX Services on z/OS doesn't always interpret every possible failure code, so sometimes it's necessary to go hunting. A good first start would be to catch the exception you're getting and look for the ERRNO/ERRNO2 values - they can give you a good hint.
If you have traditional z/OS facilities, your friend is the console log...SDSF's Log function or equivalent. There very well might be an x06 abend and a CSV... message on the console that would give you the clues about what to do next.
The solution is to use the actual command instead of the alias command in this case the actual command is onetstat, netstat is an alias command.
The problem is with the alias commands, when you try execute a alias command through the java runtime its failing to execute them. I am yet to find the exact reason but the problem could be replicated easily by the creating an alias for any command try executing them, you can try this in windows environment as well.
I'd like to know how it is started. What is the command to start this java process ? What I mean is I have one running java process, and I'd like to know the command to start it, such as what is the main class and what is the arguments, etc.
Any tool for that ? Thanks
There is a command line tool that comes with the JDK: jps, that will give you the list of java processes being run at the moment you execute the command, the arguments given to the method main and the parameters used for the JVM. Try this:
path\to\jdk\bin\jps -m -l -v
It won't give you the exact command used to start the process, but it will give you a hint of how to "rebuild" that command.
For more info, if you are on a decent distro of linux, try man jps or if you are on Windows, see the Oracle documentation about jps.
Your question wasn't clear. If you are looking to find the command that launched this process than you can look at the property sun.java.command. This will give you the main class name and arguments passed to it. java.class.path property gives you the class path. You can get the arguments passed to the java command itself by using ManagementFactory.getRuntimeMXBean().getInputArguments() method. Using all these you should be able to reconstruct the java command.
If you use Windows, you can use the Taskmanager, go to the Process/Details Tab, where you can see the PID for each Process. There you can add a column for the command line (e.g. in German its "Befehlszeile", i'm not sure how that column is labeled in English).
Then just look at the java.exe/javaw.exe Processes.
You could also use the alternative Taskmanager from Microsoft, Process Explorer, afaik there you can just click right on a process and select details.
I am trying to do something using system exec in Java
Runtime.getRuntime().exec(command);
Surprisingly everything that is related with paths, directories and files is not working well
I don't get why and just want to know is there any alternatives?
The alternative is to use the ProcessBuilder class, which has a somewhat cleaner interface, but your main problem is probably related to how the OS processes command lines, and there isn't much Java can do to help you with that.
As noted above, cd is a shell builtin. i.e. it's not an executable. You can determine this using:
$ which cd
cd: shell built-in command
As it's not a standalone executable, Runtime.exec() won't be able to do anything with it.
You may be better off writing a shell script to do the shell-specific stuff (e.g. change the working directory) and then simply execute that shell script using Runtime.exec(). You can set PATH variables etc. within your script and leave Java to simply execute your script.
One thing that catches people out is that you have to consume your script's stdout/stderr (even if you throw it away). If you don't do this properly your process will likely block. See this SO answer for more details.
The exec() method can take three arguments. The third is the directory your subprocess should use as its working directory. That solves your "cd" problem, anyway.
The following doesn't work in Java (an exception is thrown):
Runtime.getRuntime().exec("cd mydir; myprog");
The same works fine in PHP:
exec("cd mydir; myprog");
What exactly is different in Java's implementation and why (it seems more limited at first glance)?
the java exec command does not use the system command interpreter. something like "cd mydir; myprog" depends on the system command line interpreter (e.g. on windows cmd, on linux sh) to split that into 2 separate commands and execute each of them. java does not invoke the system command interpreter, so that does not work. you either need to call each command separately, or invoke the desired interpreter yourself as part of the command line.
I've seen people have problems like this, and I'm sure there are several ways, however the one I've seen most people reply is this. add cmd before it.
Runtime.getRuntime().exec("cmd cd mydir; myprog");
Assuming you're running an applet, not Java in a CLI environment on the server? If so, then your Java runtime is running on the client computer, not the server.
Java also has a better way to handle multiple commands than your semicolon. Instead of using the signature:
Runtime.exec(String)
try using this for each of your commands:
Runtime.exec(String[])
and make each argument of your command an element in the String array.