At runtime, if the JVM crashes, it will generate JVM crash logs that provide details about why it crashed. These logs get written to a directory that is inside the container and no longer available after the container crashes. This is no fun because you can't figure out why the JVM crashed.
Possible Solution
If your JVM is crashing, what you can do is this:
When you run your container, attach a volume mount to some arbitrary and presently unused location, like /jvm-crashes.
Set JAVA_TOOL_OPTIONS to include the -XX:ErrorFile=/jvm-crashes/hs_err_<my-app>.log (replace <my-app> with something to identify your app).
Restart your application container.
When it crashes next, it will write the file to the volume mount and you can retrieve it from there.
Two notes of caution:
If you have multiple instances of your container and you mount the same volume to all of them, they will all try to write crash logs to the same location. There's no way presently to insert a unique identifier into the path/filename to prevent this type of collision. This is unlikely to cause problems, but if you have multiple instances that crash at the same time, only one of the files is going to end up on the volume mount (or maybe you get some weird mix of both).
If your application crashes multiple times, you're only going to see the most recent crash log file. Again, there's no unique identifier or date/timestamp in the file name so as it crashes over and over, it will just overwrite the previous crash logs.
Describe the Enhancement
At runtime, if the JVM crashes, it will generate JVM crash logs that provide details about why it crashed. These logs get written to a directory that is inside the container and no longer available after the container crashes. This is no fun because you can't figure out why the JVM crashed.
Possible Solution
If your JVM is crashing, what you can do is this:
/jvm-crashes.JAVA_TOOL_OPTIONSto include the-XX:ErrorFile=/jvm-crashes/hs_err_<my-app>.log(replace<my-app>with something to identify your app).When it crashes next, it will write the file to the volume mount and you can retrieve it from there.
Two notes of caution:
If you have multiple instances of your container and you mount the same volume to all of them, they will all try to write crash logs to the same location. There's no way presently to insert a unique identifier into the path/filename to prevent this type of collision. This is unlikely to cause problems, but if you have multiple instances that crash at the same time, only one of the files is going to end up on the volume mount (or maybe you get some weird mix of both).
If your application crashes multiple times, you're only going to see the most recent crash log file. Again, there's no unique identifier or date/timestamp in the file name so as it crashes over and over, it will just overwrite the previous crash logs.
Motivation
Being able to see debug logs in important.