RV.conf.lock preventing RV from being launched

we have recently updated RV in our studio to 2022.3.1, after the update multiple instances of RV not being launched were reported, on investigation it was found that a lock file was generated and some process did not have permission on it. we were able to work around by closing all open RVs and deleting that lock file,

relevant section in strace that showed it was due to lock file

[pid 111096] open("~/.config/TweakSoftware/RV.conf.lock", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
[pid 111096] stat("~/.config/TweakSoftware/RV.conf.lock", {st_mode=S_IFREG|000, st_size=0, ...}) = 0
[pid 111096] open("~/.config/TweakSoftware/RV.conf.lock", O_WRONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
[pid 111096] close(57)                  = 0
[pid 111096] unlink("~/.config/TweakSoftware/RV.conf.lock.rmlock") = 0
[pid 111096] nanosleep({tv_sec=6, tv_nsec=400000000},  <unfinished ...>
[pid 111820] <... restart_syscall resumed>) = -1 ETIMEDOUT (Connection timed out)
[pid 111820] futex(0x7f2147ffea58, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 111820] futex(0x7f2147ffea84, FUTEX_WAIT_BITSET_PRIVATE, 1, {tv_sec=7230, tv_nsec=309554551}, 0xffffffff <unfinished ...>
[pid 111096] <... nanosleep resumed>0x7ffc02763910) = 0
[pid 111096] open("~/.config/TweakSoftware/RV.conf.lock", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = -1 EEXIST (File exists)
[pid 111096] open("~/.config/TweakSoftware/RV.conf.lock", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
[pid 111096] stat("~/.config/TweakSoftware/RV.conf.lock", {st_mode=S_IFREG|000, st_size=0, ...}) = 0
[pid 111096] stat("~/.config/TweakSoftware/RV.conf.lock", {st_mode=S_IFREG|000, st_size=0, ...}) = 0
[pid 111096] open("~/.config/TweakSoftware/RV.conf.lock.rmlock", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 57
[pid 111096] flock(57, LOCK_EX|LOCK_NB) = 0

Note: I have changed the absolute home directory path to ā€œ`ā€ in the original trace

can we have more info on when lock files are created and any advise on configuration that will help up to prevent this situation is appreciated

It has been mentioned a few times in bug fix reports, so I think Iā€™m in the clear to say that prefs are handled by the QSettings class in Qt, so looking to behaviors defined by that might help.

-Kessler