Lockfiles are not created/checked when loading from keystore cache

[nflaig]

When loading from keystore cache file we are currently not checking if a .lock for any of the keystores exists and the cache file itself does not have a lock file.

It is not possible to load the cache file is stored in dataDir and if you start a 2nd validator with same dataDir you would get ✖ Error: Database is not open but if a VC has a cache file it will not create lock files which is dangerous.

Originally posted by @nflaig in #5357 (comment)

[h4l]

I just discovered this behaviour myself while debugging an unrelated file permission error. A workaround (if running in a container) is to disable the cache by mounting a tmpfs at <dataDir>/cache so that the cached keys are not persisted.

I would guess that the path of the cache could change across versions and shouldn't be relied on though. I could open another issue, but would you be open to having an option to disable the keystore cache? Aside from this workaround, It would be nice to not leave decrypted keys on disk. (I see the code has an option to disable it, but I think it's not possible to control that option via the global options.)

[nflaig]

We can add a CLI flag to disable the cache but there no disadvantage of having it enabled besides what is mentioned in this issue.

It would be nice to not leave decrypted keys on disk.

There should not be decrypted keys on disk, the keystore cache file is encrypted by combining the password of all keystore files. This also means that if you remove or add a new keystore to importKeystores, the cache file will be invalidated as it can no longer be decrypted.

I could open another issue, but would you be open to having an option to disable the keystore cache?

Let's discuss it here first, I can create an issue but would like to better understand what are the use cases for disabling the keystore cache.

[h4l]

There should not be decrypted keys on disk, the keystore cache file is encrypted by combining the password of all keystore files.

Ah OK good, I missed that. My concern is invalid then. I don't have a use case for disabling it other than as a workaround for this, so no need to add a flag I think. Thanks!