Have you checked logs?
If you are running linux, check your process (using something like htop). I am having issues since an upgrade from 5.6 to 5.9 and then 5.10 with all CPUs maxing out. Have managed to isolate it out by fiddling with the group hierarchy, but still not a great resolution.
Similar symptoms to yours, where updates stop happening, then on restarting it clears out the maxed out processes and things are normal for a while.
Be really interested to know what you find.
Hello everyone,
I've identified a similar situation in my environment with version 5.12 as well. Upon analyzing the log using the grep
command and filtering by the device ID and connection ID, I noticed that a deviceOffline
event was generated for a device that was online and sending information to the server. However, I don't understand why it was considered offline. Does anyone have any idea what could be causing this? Please check the log below:
Here are my relevant settings:
<entry key='teltonika.timeout'>900</entry>
<entry key='status.timeout'>1800</entry>
<entry key='server.timeout'>3600</entry>
Device: Teltonika FMC920
Are you sure you didn't filter the logs?
Hi Anton,
I filtered the log by the Device ID and Connection ID (grep -P "deviceid|connection id"
) to investigate this specific connection.
As you can see, the deviceOffline
event occurred at 2024-03-27 09:26:16
. I then checked if any timeouts occurred from this Connection ID in the meantime, but I only found a timeout from another Connection ID. It seems like the server generated the deviceOffline
event for the wrong device. Consequently, my device continued to send data, but the server couldn't find the Connection ID anymore.
I'm not entirely sure, but consider the following observations:
[1] The Device ID is 86541XXXXXX7318
, and its Connection ID at this time was T85e902fc
:
grep 86541XXXXXX7318 /opt/traccar/logs/tracker-server.log
[2] At 2024-03-27 09:26:16
, the Connection ID Tb91ec750
was disconnected/closed. This Connection ID belonged to another device (807XXXX83):
grep "^2024-03-27 09:28:1" /opt/traccar/logs/tracker-server.log
[3] Another Connection ID was generated, but the deviceOffline
event was not generated for device 807XXXX83
:
grep -P "807XXXX83" /opt/traccar/logs/tracker-server.log
[4] At 2024-03-27 09:26:16
, a deviceOffline
event occurred for device 86541XXXXXX7318
, but its connection remained open and continued to receive data:
grep -P "86541XXXXXX7318|T85e902fc" /opt/traccar/logs/tracker-server.log
Ooops, sorry, the second screenshot link: https://ibb.co/Zc1zgcm
I don't believe that you grepped on connection because then we should see disconnected event. It should look something like this:
2024-03-27 00:00:00 INFO: [T85e902fc] disconnected
I checked the disconnected information for T85e902fc
, but it occurred approximately 6 hours later, at 2024-03-27 15:03:47
:
2024-03-27 15:03:47 INFO: [T85e902fc] timed out
2024-03-27 15:03:47 INFO: [T85e902fc] disconnected
However, I couldn't determine:
deviceOffline
event for device 86541XXXXXX7318
.T85e902fc
connection after the deviceOffline
event was generated (between 2024-03-27 09:26:16
and 2024-03-27 15:03:47
). Apparently, it was neither decoded nor filtered; it was simply ignored.I mean, all this data was lost:
And you're using the latest official release without any modifications to the code or configuration file, right?
Yes, I'm using the latest official release (5.12) without any modifications.
Could you please clarify what triggers the deviceOffline
event? I believe it's related to a connection timeout from the server or a connection closure from the device, correct? However, shouldn't we always expect to see the INFO disconnected
message in the log before the server generates the deviceOffline
event?
Yes, you should always have the disconnected message.
Has anyone used traccar 5.12 and has this problem? I have installed the new version and entered about 15 devices for testing. All the devices work fine for a while and then they all go offline. I already checked devices time zone, traccar time zone, server time zone. There is something that apparently causes them to disconnect from the platform. They work again if the server is restarted.
as additional information.
They had the server counted (Europe)
then buy at vpsdime (America)
The same thing happens in both cases, so I don't think it's a latency problem.
https://iili.io/JEsORqJ.png