galmon.eu/and-or raspbian trixie stop updating, resumes on systemctl restart ubxtool

[geeohgeegeeoh]

For an unknown reason, my ubxtool daemon stops updating galmon.eu. This is station 97 Brisbane Australia.

• It could be between me and my GPS USB antenna. It's a Ublox USB attached device Maaaahtin gave me years ago.
• It could be between the antenna and ubxtool
• It could be between ubxtool and galmon.eu

the device is attached to a Raspberry PI B 2+ running rasbian trixie.

I have no diagnostic, no logfile, no error message as yet. This has been happening intermittently for a few months now. I mailed about it but I suspect it went to spam. (can't blame you)

Please advise the best diagnostic I can do on this to help triage. I am git TFO up to date on the source.

[mahtin]

George,

Can you still ping from the RPi to galmon.eu after it stops updating?

Does the lsusb command still show the USB device after it stops updating?

Does restarting ubxtool vs rebooting help?

Could you add a reboot every month to your crontab and solve it that way? :)

I don't think it's the age of the device as I've got one from that age working a-ok.

^^^ just thinking aloud.

Martin

[geeohgeegeeoh]

George,

Can you still ping from the RPi to galmon.eu after it stops updating?

Yes

Does the lsusb command still show the USB device after it stops updating?

yes

Does restarting ubxtool vs rebooting help?

Yes

Could you add a reboot every month to your crontab and solve it that way? :)

... Do I have to say the word? Yes, probably.

I don't think it's the age of the device as I've got one from that age working a-ok.

I'm in a hot location. it's behind glass west facing so gets cooked with setting sun. Might be an issue but I can't correlate the failures to TOD.

^^^ just thinking aloud.

YES. But much appreciated. I will consider the WIndows "turning it off and on again" approach.

-George

[geeohgeegeeoh]

An additional data point. galmon.eu is reachable reliably as a V4 only address. submit.galmon.eu is not reliably reachable on V6.

root@galmon:/var/log# ping submit.galmon.eu
PING submit.galmon.eu (2001:41f0:782d:1::2) 56 data bytes
^C^C
--- submit.galmon.eu ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4123ms

root@galmon:/var/log# ping6 www.apnic.net.
PING www.apnic.net. (2606:4700::6812:ec44) 56 data bytes
64 bytes from 2606:4700::6812:ec44: icmp_seq=1 ttl=60 time=2.81 ms
^C
--- www.apnic.net. ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.806/2.806/2.806/0.000 ms
root@galmon:/var/log#

I tested from 3 different AS, my home, APNIC (4777) and Linode/Akamai in the US and EU (Germany)

[geeohgeegeeoh]

I modified my setup to have a v4 only FQDN for submit4.galmon.eu in /etc/hosts, changed how ubxtool is called, and I am seeing if the problem goes away.

[geeohgeegeeoh]

ok, This is what is in /run/ubxtool/stderr.log when it stops updating. the "stuffing" messsage continues ad-infinitum:

Wed, 15 Jul 2026 06:27:57 +0000 src 97 (fix: 3) currently receiving: 0,24@0 0,29@0 2,10@1 2,11@1 6,17@0 6,18@0 
Done after reading -1 bytes, flushing buffers..
Wed, 15 Jul 2026 06:28:12 +0000 Stuffing 5 messages back into the queue
Wed, 15 Jul 2026 06:28:13 +0000 Stuffing 5 messages back into the queue
Wed, 15 Jul 2026 06:28:13 +0000 Stuffing 5 messages back into the queue
Wed, 15 Jul 2026 06:28:14 +0000 Stuffing 5 messages back into the queue
Wed, 15 Jul 2026 06:28:14 +0000 Stuffing 5 messages back into the queue
Wed, 15 Jul 2026 06:28:14 +0000 Stuffing 5 messages back into the queue
Wed, 15 Jul 2026 06:28:15 +0000 Stuffing 5 messages back into the queue
Wed, 15 Jul 2026 06:28:15 +0000 Stuffing 5 messages back into the queue
Wed, 15 Jul 2026 06:28:15 +0000 Stuffing 5 messages back into the queue

[mahtin]

George,

The "Done after..." message means the process have given up and is about to exit. See ...

galmon/ubxtool.cc

Line 2109 in 59e7c8c

cerr<<"Done after reading "<<lseek(fd, 0, SEEK_CUR)<<" bytes, flushing buffers.."<<endl;

If you're using ubxtool.service then in theory ubxtool should restart. Clearly that's not fixing anything because communication has hiccuped. I think you have a core system issue or even a ... dum dum dum ... DNS issue ('cause it's always DNS). Why not try a DNS subsystem reset and see if ubxtool successfully reconnects. I believe the following ...

$ sudo systemctl restart systemd-resolved
...
$

... is the right incantation. YMMV. Test before and after.