I'm currently writing a Java daemon. I'm writing a script that will have the standard daemon commands (start, stop, restart, status) and I'm trying to decide on where things should go when installing the daemon.
My current idea is:
PID File: /var/run/myapp.pid
Daemon Script: /etc/init.d/myapp
Java App (.jar): /usr/bin/myapp
Logs: /var/log/myapp.err, /var/log/myapp.log, /var/log/myapp.info (you get the idea)
Configs: /etc/myapp.conf (or /etc/myapp/configs-go-here if I have more than one in the future)
I'm still new to the Linux directory structure so if I'm doing something wrong let me know. Whats confusing me the most is that my Java app is a .jar file (archive) and not a binary. So does that mean that /usr/bin/ isn't the "right" place for it?
You could put the .jar file in /usr/lib/myapp/myapp.jar and make the startup script do java -j /usr/lib/myapp/myapp.jar
Looking it from that side, the jar is effectively a library that the /usr/bin/java binary uses, so those locations look good to me.
The /usr/lib/myapp/myapp.jar suggestion is on the right track, but /usr/lib is for architecture-specific files - since Java jar archives are platform-independent, /usr/share/myapp/myapp.jar is a better location.
Related
I noticed a lot of file /tmp/.java_pid<...> in my Linux machine. The file command says they are sockets. Assuming they are created by Java I wonder why Java does not clean them up. How to make Java clean them up or just not create them?
These files are created by the JVM to support debugging. It's part of the attach api.
If you don't want java to create them then start java apps without debugging enabled.
You can safely delete them if there isn't a jvm with the corresponding pid... a task that is eminently suitable for a cron job.
A little bit of bash:
for file in /tmp/.java-[0-9]*; do
[ -d /proc/${file#*.java-} ] || rm -f $file
done
pid files are generally the location where applications store their process id, so the user can kill the process easily afterwards. These applications should be deleting these files when they close down.
I wouldn't worry about these files too much, unless you are seeing more and more of them and they dont get deleted, then it might be a tell tale sign that you have an application that is not shutting down correctly,
Have you had experience with running a jar file using a command line, wrapped in a Windows service?
I'm trying to find a way to run a jar file without being logged into the machine, and since it allows command shell, I was wondering if it's a good idea.
Thanks!
Original Post:
I'm trying to run Associated Press's Web Feeds Manager, which is basically a jar file that can be run when logged in by double clicking it.
I'd like to run the same file but without being logged in to the machine. In their manual (http://wfm.ap.org/admin/content/help/Running_Agent_on_a_Remote_Server.htm) they write how to do that, using a commandline parameter.
Basically I'd like the jar to run as a Windows service, regardless of who's logged in, but Googling it showed it was problematic.
Have you had experience with remotely running jar files? What are the pitfalls?
Thanks!
On a google search, I came across this article -
Running Jar Applications as a Windows Service
It mentions about open source Java Service Wrapper project from Tanukisoftware.org for accomplishing this task.
Note: I've not used this personally.
If you are not interested in having the service started/stopped at boot/shutdown, but you just want the program to be started manually and keep running after logout, here is what you do:
$ nohup java -jar foobar.jar > foobar.log 2>&1 &
which means: start my foobar.jar (java -jar) and keep it running after I logout (nohup) redirect stdout to foobar.log (>) and also the stderr (2>&1), and make it running in background (& at the end).
Instead, if you are interested in installing a "service" in your linux box, there are many options, depending on what distribution you are using.
The most common are upstart (for ubuntu) and System V init scripts (Redhat or others). Also cron can be used to start/stop services at startup/shutdown.
You can find an example of installing a java app (hudson) on an init system here, or doing the same thing with upstart. Or, as I said, cron could be an option.
On Windows, there is Java Service Wrapper. And not much more.
For windows Java Service Wrapper is a better choice
My favourite is the upstart on linux, but it is Ubuntu only.
On Windows I see many alternatives according to this forum.
I have a Java process (daemon) which is running. This process is used like a service. With that service I can download a signed zip archive from a trusted server. After I unpack the ZIP archive I want to execute a binary in the "unpacked" folder.
The problem is that this binary is not executable (no 'x' in its file mode) ... I know it's possible to set it with Java but I want a generic way.
Do you have any ideas how to do the deployment in a nice way?
(Yes, it needs to be Java)
Basically I want to restore the Unix file mode bits after I unpacked the ZIP archive. Is there a Java Lib which can do this?
You could easily call the chmod command from your Java application to add that missing x bit. chmod is as standard on Unix as the executable (x) bit itself.
Or you could do it straight from Java.
If you want the executable bit to remain set at decompression, though, you should probably not use the Java decompression libraries. Try using the Unix unzip command to decompress your archive - it has supported storing and restoring the Unix file mode bits for quite some time. If your Unix vendor does not have it, you can get it from the source.
If you pack your files with tar and then optionally compress, it keeps your permissions as they were before packing. Use --preserve-permissions when unpacking.
I have a Java application that needs to implement installation features of making a JAR launch on startup.
I can do this on Window by entering a REG file into the registry, but how can I do this on UNIX platforms? Linux and Mac if the methods are different.
Do Linux and Mac have system startup folders?
Remember that I need to do this programmatically not through system preferences or anything like that.
On Linux, the classic way would be through adding a script in the appropriate /etc/rcN.d/ directory (where N is a number 0-6 representing the 'run level'). I'm not sure whether that's still the recommended way, but it usually is still supported. This would also work with minor variations for other mainstream Unix variants (Solaris, HP-UX, AIX).
On Mac, you have to work harder. The files /etc/rc.common, /etc/rc.imaging and /etc/rc.netboot are related, but there are no /etc/rcN.d directories. There's also a script rc and another rc.local. Typing man rc reveals:
DESCRIPTION
rc.local is now unsupported and has been replaced with launchd(8), which bootstraps itself via the launchctl(1) bootstrap subcommand to read in launchd(8) jobs from the standard locations.
SEE ALSO
launchd(8), launchctl(1)
So, you should investigate launchctl and launchd, particularly launchctl.
This is how I would do it on ubuntu.
First create a bash script to run the java app, similar to.
#!/bin/bash
java -jar "helloworld.jar"
and save it, in this case called 'HELLOWORLD' in /etc/init.d.
Need to make the script executable so need to run
chmod +x HELLOWORLD
Finally to make it run on start up
update-rc.d HELLOWORLD defaults
On Macs I think its launchd, and on linux its init.d. They are config files.
I developed a project using Java and now I've to deliver it to client who is using Linux. Which executable file format will be delivered and how to make that?
Executable file format?
If you're delivering a Java app, give them a jar file (and associated libs).
Provide a shell script to set up its environment and execute it.
For example, assuming I define ROOT_DIR as my app's install directory, and so on:
CLASSPATH="${ADD_JARS}:${CLASSPATH}:${ROOT_DIR}/lib/myApp.jar:\
${ROOT_DIR}/lib/jibx/jibx-run.jar:\
${ROOT_DIR}/lib/jibx/xpp3.jar:\
${ROOT_DIR}/lib/bindings.jar:\
${ROOT_DIR}/lib/commons-lang-2.0.jar:\
${ROOT_DIR}/lib/forms-1.0.5.jar"
"${JAVACMD}" -Xmx256M -DanyDefsNeeded=foobar -Dbase.dir="${ROOT_DIR}" -cp "${CLASSPATH}" myApp.main.Launcher "$#"
What goes into the shell script depends totally on what your app actually needs to start up.
A jar. If it is not executable, then a script (.sh) to launch the jar.
Well basically what you wanna put in a .sh file is the commands you'd normally type at the console to run your jar file. They should be separated by a new line (i.e. each on a separate line in the .sh file).
The most basic you can go is add something like this to your sh file:
java -Xms=64m -Xmx=256m -jar myJar.jar -classpath [dependencies dir]/dep1.jar,[dependencies dir]/dep2.jar
beyond this you can do more exotic stuff, like parametrise some environment variables, get command line argumens from when the .sh is launched and pass them to the jar executatble etc. Look up "bash scripting" for advanced stuff:
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-2.html#ss2.1
You might have better luck using Launch4J, IzPack or other installer that has cross-platform capabilities. This might be a better first option than trying to understand the intricacies and idiosyncrasies of the different Linux distributions and shells.
If your app. has a GUI, the best user experience for installation/deployment can be had by way of Java Web Start. Note that JWS can deploy apps. to Windows, *nix and Mac. and avoids all the maintenance woes of generating 3 separate (platform specific) executables.