I see this from time to time, rectified with 'sudo pkill wsjtx' and
then no problem to start a new session.. If linux > wsjtx ran a startup
script killing first,
then there would never be an issue.
73
Adrian Fewster
On 5/11/22 22:56, leo bistmans via wsjt-devel wrote:
Via strace I saw the lock file that is not there is /tmp/WSJT-X ... .lock
openat(AT_FDCWD, "/tmp/WSJT-X - ft-891.lock",
O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 13
flock(13, LOCK_EX|LOCK_NB) = 0
If I create it myself with touch, the switch code below is used
instead of throwing the fatal error.
The code in main.cpp:
// disallow multiple instances with same instance key
QLockFile instance_lock {temp_dir.absoluteFilePath
(a.applicationName () + ".lock")};
instance_lock.setStaleLockTime (0);
while (!instance_lock.tryLock ())
{
if (QLockFile::LockFailedError == instance_lock.error ())
{
auto button = MessageBox::query_message (nullptr
, "Another
instance may be running"
, "try to
remove stale lock file?"
, QString {}
,
MessageBox::Yes | MessageBox::Retry | MessageBox::No
, MessageBox::Yes);
switch (button)
{
case MessageBox::Yes:
instance_lock.removeStaleLockFile ();
break;
case MessageBox::Retry:
break;
default:
throw std::runtime_error {"Multiple instances must
have unique rig names"};
}
}
else
{
throw std::runtime_error {"Failed to access lock file"};
}
}
The reason that I do not have the .lock file in /tmp is an open
question to me ( possibly a disk full condition? ).
However I think it is fairly safe for wsjt-x to just start instead of
forcing me to reboot my PC.
73 de on1aad
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
