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

admin管理员组

文章数量:1026989

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?

• java
• linux
• install4j
• nfs

Share Improve this question Follow asked Nov 19, 2024 at 2:00 Peter HollemansPeter Hollemans 15999 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: 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.

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?

• java
• linux
• install4j
• nfs

Share Improve this question Follow asked Nov 19, 2024 at 2:00 Peter HollemansPeter Hollemans 15999 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: 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.

本文标签：