How would I make my Java application delete itself and then close out of itself on a Mac/Linux OS? I have tried a couple Runtime commands, but none of them seem to work.
Something like this maybe:
try {
Runtime.getRuntime().exec(new String[]{"/bin/sh", "-c", "rm \"" + getRunningJarPath() + "\""});
} catch (final IOException e) {}
Note: The method: getRunningJarPath IS accurate.
Generally, it's not possible: you program may happen not to have rights to remove itself.
Additionally, there's a problem: while your program is running, JVM holds a read lock on the JAR, so it well may be that you cannot delete it right away.
Usually, you run your program from a script which would check the exit code and remove the files if necessary.
You can create a cron job to delete file, that will start after a delay
You do not state why you want the program to be deleted afterwards.
Anyway, you should not rely on manipulating the file system yourself. I would suggest you look into Java WebStart instead as it provides all the file system caching (including expiration) you need.
Related
I want to run linux script from Java program and continue to execute program only when script stop. I am not interested to read script output ... Can anybody help me?
Thanks a lot,
and excuse me for my bad English
Assuming all other threads are idle:
// run the script.
Process proc = Runtime.getRuntime().exec("/path/to/myscript");
// wait for the return code.
int ecode = proc.waitFor();
If you have more complex arguments to your script, or it needs to monitor STDOUT, STDERR, or needs other modifications (like feeding data to STDIN, or changing execution directory, environment variables, etc.) then you should do the same effective procedure, but instead of using Runtime.exec(...) you should build and start the Process manually. Read the Process javadoc and ProcessBuilder javadoc on how to set it up, and start it.
You can also launch the bash interpreter instead
Process proc = Runtime.getRuntime().exec("/bin/bash /path/to/myscript");
int ecode = proc.waitFor();
This may work in some generally broken cases when #rolfl solution may not work (non executable script file, #!/ header missing, etc)
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.
in a Java application I need to run an external console application. With the window's ones everything is OK:
try {
System.out.println("Running...");
Runtime.getRuntime().exec("notepad.exe");
System.out.println("End.");
}
catch(Exception e) {
System.out.println(e.getMessage());
}
launches notepad successfully.
But if I put D:\\MyProg.exe or .bat or even cmd.exe (which is it PATH as notepad is) it does not work. Without any exeptions. Just:
Running...
End.
First off, most likely Runtime.exec() is returning asynchronously, so just printing "end" will always work, since the exec call returns immediately, which is what you're seeing.
There's a bunch of other problems that could be showing up here. I think what is happening is that the programs you are calling might be outputting I/O on stdout that you are failing to read, or perhaps you need to wait for it to finish before exiting the java process. There's a great article on the various problems with Runtime.exec() you should probably read, it covers this and other problems.
It is because notepad placed in special folder and this folder exists in Path variable.
Run cmd using following line:
Runtime.getRuntime().exec("cmd.exe /c start");
Run other application:
Runtime.getRuntime().exec("cmd.exe /c start C:\\path\\to\\app.exe");
I'm using Eclipse to develop a Java program, and figured I'd add an option to my program to parse stdin if there are no arguments. (otherwise it parses a file)
I am having problems if I execute "somecommand | java -jar myjar.jar" and went to debug... then realized I don't know how to start a process in Eclipse like that. And if I run it on the command prompt, I can't attach to a running process since the process starts immediately.
Any suggestions on how to debug?
edit: see, the thing is, I wrote my program originally to take a filename argument. Then I figured it would be useful for it to take stdin as well, so I did abstract InputStream out of my program (as Mr. Queue suggests). It works fine operating on a file (java -jar myjar.jar myfile), but not operating when I run type myfile | java -jar myjar.jar. I suspect that there's something different in the two scenarios (eof detection is different?) but I really would like to debug.
// overall program structure follows:
public static void doit(InputStream is)
{
...
}
public static void main(String[] args)
{
if (args.length > 0)
{
// this leaves out the try-catch-finally block,
// but you get the idea.
FileInputStream fis = new FileInputStream(args[0]);
doit(fis);
fis.close();
}
else
{
doit(System.in);
}
}
Run your app, with the pipe, on the command line but add JVM args for remote debugging, like this:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1044
suspend=y will tell the JVM to not actually run the program until the debugger is attached.
Next, go into the Eclipse debug launch configurations (Run -> Debug Configurations...) and create a "Remote Java Application" to connect to your app. Run the launch in Eclipse (after setting some breakpoints) and you should be able to debug. Not terribly convenient, but if you can't reproduce your issues without the pipe, this is an option.
If I'm interpreting your question right, I believe you just want to know how to send input across standard in and debug through it in eclipse.
If it's simple input, you can actually manually enter System.in data via the eclipse Console window while the program is running. Just start typing in the console window, and press enter to send the text to Standard in.
If it's something more complicated, I'd suggest abstracting the read you're trying to do to take an InputStream. In your program, you can send System.in as the InputStream. To Debug, you can send any other InputStream. For example, you could put your input in a file, and pass a FileInputStream to the method to test it.
EDIT:
Without seeing some more code, I'm not sure, but you might be on to something with eof detection. A FileInputStream has a defined end of file, but I'd guess System.in has nothing of the sort. Your reader might just be waiting to read the next character and never advancing. You might have to manually stop the read after you know you've read "enough".
Perhaps this solution of creating a named pipe might apply here.
mkfifo foo
somecommand > foo
Next in the debug configuration, add < foo in the args, so that your program is debugged as:
java -jar myjar.jar < foo
I'm late to the party. But you can look for the "common" tab in the debug configuration for your project. There, you should be able to see a section labeled "Standard Input and Output". You can allocate the console with input files and set output files this way.
I have a Java program that I'd like to daemonize on a linux system. In other words, I want to start running it in a shell and have it continue running after I've logged out. I also want to be able to stop the program cleanly.
I found this article which uses a combination of shell scripting and Java code to do the trick. It looks good, but I'd like something simpler, if possible.
What's your preferred method to daemonize a Java program on a Linux system?
Apache Commons Daemon will run your Java program as Linux daemon or WinNT Service.
If you can't rely on Java Service Wrapper cited elsewhere (for instance, if you are running on Ubuntu, which has no packaged version of SW) you probably want to do it the old fashioned way: have your program write its PID in /var/run/$progname.pid, and write a standard SysV init script (use for instance the one for ntpd as an example, it's simple) around it. Preferably, make it LSB-compliant, too.
Essentially, the start function tests if the program is already running (by testing if /var/run/$progname.pid exists, and the contents of that file is the PID of a running process), and if not run
logfile=/var/log/$progname.log
pidfile=/var/run/$progname.pid
nohup java -Dpidfile=$pidfile $jopts $mainClass </dev/null > $logfile 2>&1
The stop function checks on /var/run/$progname.pid, tests if that file is the PID of a running process, verifies that it is a Java VM (so as not to kill a process that simply reused the PID from a dead instance of my Java daemon) and then kills that process.
When called, my main() method will start by writing its PID in the file defined in System.getProperty("pidfile").
One major hurdle, though: in Java, there is no simple and standard way to get the PID of the process the JVM runs in.
Here is what I have come up with:
private static String getPid() {
File proc_self = new File("/proc/self");
if(proc_self.exists()) try {
return proc_self.getCanonicalFile().getName();
}
catch(Exception e) {
/// Continue on fall-back
}
File bash = new File("/bin/bash");
if(bash.exists()) {
ProcessBuilder pb = new ProcessBuilder("/bin/bash","-c","echo $PPID");
try {
Process p = pb.start();
BufferedReader rd = new BufferedReader(new InputStreamReader(p.getInputStream()));
return rd.readLine();
}
catch(IOException e) {
return String.valueOf(Thread.currentThread().getId());
}
}
// This is a cop-out to return something when we don't have BASH
return String.valueOf(Thread.currentThread().getId());
}
I frequently find myself writing scripts or command lines which essentially look like this, if I want to:
Run a program that is immune to sighups
That is completely disconnected from the shell which spawns it, and
Produces a log file from stderr and stdout the contents of which are displayed as well, but
Allows me to stop viewing the log in progress and do other stuff without disrupting the running process
Enjoy.
nohup java com.me.MyProgram </dev/null 2>&1 | tee logfile.log &
I prefer the nohup command. The blog post says there are better ways, but I don't think they're enough better.
You could try Java Service Wrapper, the community edition is free and meets your needs.
My preferred way on Ubuntu is to use the libslack 'daemon' utility. This is what Jenkins uses on Ubuntu (which is where I got the idea.) I've used it for my Jetty-based server applications and it works well.
When you stop the daemon process it will signal the JVM to shutdown. You can execute shutdown/cleanup code at this point by registering a shutdown hook with Runtime.addShutdownHook().
That depends. If it's just a one-time thing, I want to daemonize it and then go home, but usually I wait for the results, I might do:
nohup java com.me.MyProgram &
at the command line. To kill it cleanly, you have a lot of options. You might have a listener for SIGKILL, or listen on a port and shutdown when a connection is made, periodically check a file. Difference approaches have different weaknesses. If it's for use in production, I'd give it more thought, and probably throw a script into /etc/init.d that nohups it, and have a more sophisticated shutdown, such as what tomcat has.
DaemonTools :- A cleaner way to manage services at UNIX https://cr.yp.to/daemontools.html
Install daemon tools from the url https://cr.yp.to/daemontools/install.html
follow the instruction mentioned there,for any issues please try instructions https://gist.github.com/rizkyabdilah/8516303
Create a file at /etc/init/svscan.conf and add the below lines.(only required for cent-os-6.7)
start on runlevel [12345]
stop on runlevel [^12345]
respawn
exec /command/svscanboot
Create a new script named run inside /service/vm/ folder and add the below lines.
#!/bin/bash
echo starting VM
exec java -jar
/root/learning-/daemon-java/vm.jar
Note:
replace the Jar with your own Jar file. or any java class file.
Reboot the system
svstat /service/vm should be up and running now !.
svc -d /service/vm should bring vm down now !.
svc -u /service/vm should bring vm up now !.
This question is about daemonizing an arbitrary program (not java-specific) so some of the answers may apply to your case:
Take a look here:
http://jnicookbook.owsiak.org/recipe-no-022/
for a sample code that is based on JNI. In this case you daemonize the code that was started as Java and main loop is executed in C. But it is also possible to put main, daemon's, service loop inside Java.
https://github.com/mkowsiak/jnicookbook/tree/master/recipes/recipeNo029
Have fun with JNI!
nohup java -jar {{your-jar.jar}} > /dev/null &
This may do the trick.