Document launcher's use of temp directory for libraries that require unpacking

[ggajos]

Hello,

I have a case where I need to unpack the library using the:

spring-boot:repackage:requiresUnpack

Otherwise, the other library from the project is not able to work properly. As stated in the link, the selected libraries are unpacked and copied over to the temporary directory. Unpacking the libraries to the temp directory isn't great idea if I would like to keep the application running longer that the temp files expiration time. The files would be removed by linux and the application will just stop working properly.

• Is there a way to specify the different target directory?
• Is there a reason why the temp location is good place for the application libraries? Isn't that a serious bug?

So far, I was able to change the location target location via overwriting the TMP and TEMP environment variables but that sounds like terrible idea in the long run.

Appriciate any help here.

[philwebb]

Is there a way to specify the different target directory?

Not currently, but it might be an interesting enhancement if you could specify an unpack location, perhaps in an environment variable.

Is there a reason why the temp location is good place for the application libraries? Isn't that a serious bug?

It seems like the only logical place that we can unpack JARs. It's a folder that's available on all operating systems and it's writable. I'm not sure what other choice we can make here, but we're open to suggestions.

So far, I was able to change the location target location via overwriting the TMP and TEMP environment variables but that sounds like terrible idea in the long run.

Fat jars can also run exploded. Perhaps you'd be better off unzipping the jar then running from the exploded folder.

[ggajos]

Is there a way to specify the different target directory?

Not currently, but it might be an interesting enhancement if you could specify an unpack location, perhaps in an environment variable.

Thank you for the confirmation.

Is there a reason why the temp location is good place for the application libraries? Isn't that a serious bug?

It seems like the only logical place that we can unpack JARs. It's a folder that's available on all operating systems and it's writable. I'm not sure what other choice we can make here, but we're open to suggestions.

This is an unreliable and very risky place. We thought that unpacking fix the issue with our library but it backfires badly. I assumed that requiresUnpack is placing the files somewhere, where they will be available all the time when the application is running, for example:

• Local directory ./unpacked/, where user start the jar (I know it might be tricky to resolve)
• User home directory `./.springboot/unpacked/safehere

Basically, any place that won't be deleted as standard OS cleanup procedure. Default option here is not able to keep the application up and running for more than 10 days on Red Hat for example (other distros have different timing).

So far, I was able to change the location target location via overwriting the TMP and TEMP environment variables but that sounds like terrible idea in the long run.

Fat jars can also run exploded. Perhaps you'd be better off unzipping the jar then running from the exploded folder.

Thank you, I will explore this options as well. The fat jar is great for deployment management (upgrading/updating). The requiresUnpack is also a great feature that is doing exactly what is needed, It just has to be reliable.

[wilkinsona]

• Local directory ./unpacked/, where user start the jar (I know it might be tricky to resolve)
• User home directory `./.springboot/unpacked/safehere

Thanks for the suggestions. Unfortunately, in a locked-down production environment, there's no guarantee that either the working directory or the user's home directory will be writable by the user running the app. In fact, we'd generally recommend that they are not as it helps to minimise the risks if a security vulnerability is exploited.

We can certainly consider making the unpack location configurable. We could also look at a mechanism to access the files periodically so they aren't deleted. If it's possible, this might be preferable as it doesn't add the external complexity of a configuration option. In the meantime, I would recommend modifying your configuration for systemd-tmpfiles or tmpwatch to not delete the unpacked jars prematurely.

[ggajos]

Thank you @wilkinsona for the comment here.

We could also look at a mechanism to access the files periodically so they aren't deleted

This sounds really good as it will by default prevent from the surprise. The update of systemd-tmpfiles and tmpwatch is the quickfix that we've already applied on the servers (so we can investigate the solution). However, we have many bundles deployed, so I wanted to explore the "right" approach here.

Right now, I will go with updating the temp location via -Djava.io.tmpdir, it will solve the problem for other bundles as well.

[philwebb]

We're not keen to add any additional complexity around the unpack option so instead we'll improve the documentation around this.