Re: [wsjt-devel] "Failed to access lock file" in wsjt-x 2.6.0 rc4
Well,
IMHO this issue is pretty annoying also because from the lock stale
warning window we cannot remove the file and as I told in other
occasions, the same problem is present in every WSJT-X release I used
from the very beginning.
Beside this, more precisely with 2.6.0 RC4, I noticed an increase of
occurrences of the processes hanging in the background (I think it being
the JT9 process...) and a manual intervention is necessary to kill them
in order to restart the main program.
In addition from time to time, I noticed with RC4 a sudden lost of audio
communication (both in TX and RX) between WSJT-X and the default
computer sound system and again to get it sorted out, I need to delete
the WSJT-X.lock file by hand and restart the main program.
Regards,
---
*73 de Marco, PY1ZRJ (former IK5BCU)*
**
Il 05/11/22 10:06, Adrian via wsjt-devel ha scritto:
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
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] "Failed to access lock file" in wsjt-x 2.6.0 rc4
adrian@debian:~$ ps ax | grep wsjt
57603 ? Sl 1:11 /usr/bin/wsjtx
62851 pts/3 S+ 0:00 grep wsjt
adrian@debian:~$ sudo pkill wsjtx
adrian@debian:~$ ps ax | grep wsjt
63624 pts/3 S+ 0:00 grep wsjt
adrian@debian:~$
It is process wsjtx rather than wsjt, but your grep should have picked
it up as above.
In my case, any stale lock file error is resolved as above.
I never have to reboot.
73
Adrian Fewster
On 5/11/22 23:28, leo bistmans wrote:
I did try to look for lingering wsjtx related processes, but did not
see them:
leo@linux-gu90:/tmp> ps ax | grep wsjt
3140 pts/3 S+ 0:00 grep --color=auto wsjt
leo@linux-gu90:/tmp> ps ax | grep jt
3208 pts/3 S+ 0:00 grep --color=auto jt
On Sat, Nov 5, 2022 at 2:06 PM Adrian wrote:
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
Re: [wsjt-devel] "Failed to access lock file" in wsjt-x 2.6.0 rc4
I did try to look for lingering wsjtx related processes, but did not see
them:
leo@linux-gu90:/tmp> ps ax | grep wsjt
3140 pts/3S+ 0:00 grep --color=auto wsjt
leo@linux-gu90:/tmp> ps ax | grep jt
3208 pts/3S+ 0:00 grep --color=auto jt
On Sat, Nov 5, 2022 at 2:06 PM Adrian wrote:
> 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
Re: [wsjt-devel] "Failed to access lock file" in wsjt-x 2.6.0 rc4
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
[wsjt-devel] "Failed to access lock file" in wsjt-x 2.6.0 rc4
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
