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 in
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 shou
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 wrot
Exclude that directory from your antivirus scanning.
Mike W9MDB
On Saturday, November 5, 2022 at 01:56:35 AM CDT, Alex Deligiannis via
wsjt-devel wrote:
I’m using WJT-x rc4 from the first day and worked without any problem till few
days ago, now from time to time I get the error
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 th
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
