java - Are there workarounds for using install4j launchers on multiple machines with NFS mounted home directories? - Stack Overf

I'm trying to run install4j-produced launcher scripts on various different Linux servers (CentOS 9

I'm trying to run install4j-produced launcher scripts on various different Linux servers (CentOS 9), each of which has it's own custom JRE installed in the software's home directory, but all of which have the same home directory mounted via NFS. The issue is that the ~/.cache/install4j/jre_version file every so often gets corrupted, possibly when NFS is connecting or disconnecting, so that it ends up containing a JRE_INFO line for some specific JRE, but no JRE_VERSION line. In that scenario, the install4j launcher will think that the JRE version is invalid and the only way we can recover is by manually deleting the jre_version file and force it to be rebuilt. We have many launchers running automatically from many servers, and the whole data processing system gets hung up, so manual deletion isn't an option in the long term.

What I'm looking for is a workaround, for example:

  • Is there an environment variable to set to promise that the JRE is of a permitted version so jre_version does not need to be consulted?

  • Is there a way to point to a read-only jre_version file known to contain the specs for the JRE being used?

  • Is there a way to point to a jre_version file not in $HOME and thus not shared by at least a dozen distinct JREs on literally hundreds of machines?

I'm trying to run install4j-produced launcher scripts on various different Linux servers (CentOS 9), each of which has it's own custom JRE installed in the software's home directory, but all of which have the same home directory mounted via NFS. The issue is that the ~/.cache/install4j/jre_version file every so often gets corrupted, possibly when NFS is connecting or disconnecting, so that it ends up containing a JRE_INFO line for some specific JRE, but no JRE_VERSION line. In that scenario, the install4j launcher will think that the JRE version is invalid and the only way we can recover is by manually deleting the jre_version file and force it to be rebuilt. We have many launchers running automatically from many servers, and the whole data processing system gets hung up, so manual deletion isn't an option in the long term.

What I'm looking for is a workaround, for example:

  • Is there an environment variable to set to promise that the JRE is of a permitted version so jre_version does not need to be consulted?

  • Is there a way to point to a read-only jre_version file known to contain the specs for the JRE being used?

  • Is there a way to point to a jre_version file not in $HOME and thus not shared by at least a dozen distinct JREs on literally hundreds of machines?

Share Improve this question asked Nov 19, 2024 at 2:00 Peter HollemansPeter Hollemans 1599 bronze badges
Add a comment  | 

1 Answer 1

Reset to default 1

As all your servers should have a different hostname, you can set

export XDG_CACHE_HOME=~/.cache/$(hostname)

and there will be no conflict.

发布者:admin,转转请注明出处:http://www.yc00.com/questions/1745586253a4634556.html

相关推荐

发表回复

评论列表(0条)

  • 暂无评论

联系我们

400-800-8888

在线咨询: QQ交谈

邮件:admin@example.com

工作时间:周一至周五,9:30-18:30,节假日休息

关注微信