Issue with Traccar 6.13.3: Service blocking on forwarder failure and device positionId synchronization issues

RastreameMX 13 hours ago

Hello everyone,

We are experiencing some strange behavior after upgrading our server from version 6.8 to 6.13.3 about two weeks ago. We are currently facing two main issues:

Service hanging on shutdown due to server.forward
When we attempt to stop or restart the Traccar service, it hangs for a long time until systemd eventually kills it with SIGKILL (status 9).

The journalctl logs show:

Jun 04 22:16:37 Rastreame systemd[1]: Stopping traccar...
Jun 04 22:18:07 Rastreame systemd[1]: traccar.service: State 'stop-sigterm' timed out. Killing.
Jun 04 22:18:07 Rastreame systemd[1]: traccar.service: Killing process 1494755 (java) with signal SIGKILL.
Jun 04 22:18:07 Rastreame systemd[1]: traccar.service: Killing process 1494756 (java) with signal SIGKILL.
...
Jun 04 22:18:08 Rastreame systemd[1]: traccar.service: Main process exited, code=killed, status=9/KILL
Jun 04 22:18:08 Rastreame systemd[1]: traccar.service: Failed with result 'timeout'.
Jun 04 22:18:08 Rastreame systemd[1]: Stopped traccar.
Jun 04 22:18:08 Rastreame systemd[1]: traccar.service: Consumed 27.227s CPU time

We discovered that if our secondary/forwarding server is down, the server.forward feature triggers WARN: Network forwarding error - Connection refused - ConnectException (as expected) but it seems that these persistent connection errors eventually saturate the thread pool or block the whole service, preventing position receiving and processing, and a clean shutdown. Disabling server.forward resolved the shutdown blocking issue.

tc_devices.positionid not updating
We have an issue where some devices stop updating their position on the frontend.

We can confirm via SQL that tc_positions is receiving and storing new positions for these devices. Requesting a positions report, we can see latest positions are shown too.

tc_devices.lastupdate is correctly updating to the most recent timestamp.

However, tc_devices.positionid is not updating. Because of this, the /api/devices endpoint still returns an outdated positionid, and the frontend doesn't show the new location.

We have checked for future-dated positions or database integrity issues, but everything seems correct in the database.

Could someone help us understand the logic behind how Traccar determines when to update tc_devices.positionid? Have there been any recent changes to this algorithm between 6.8 and 6.13.3 that might affect this?

Any insights or guidance would be greatly appreciated. Thanks in advance!

RastreameMX an hour ago

Additional information:

Apparently, the server (using the Ruptela protocol) stopped updating the device's last position after receiving a command response packet. In the database, that specific position showed correct devicetime and servertime values, but the fixtime was set to the following day at 00:00.

Even after deleting the positions with future fixtime values, the issue was not resolved yesterday. However, as of this morning, it has been updating positions without any issues.

Are there any tables other than tc_positions and tc_events where position or event timestamps are stored that might interfere with receiving new positions if they are older than that "future" timestamp?

Thank you.

Anton Tananaev an hour ago

Fix time is always reported by device. Have you checked logs?

RastreameMX 30 minutes ago

Hi @Anton, good day.

Yes. First received positions with answers in logs appears with date and time correct :

2026-06-04 19:06:49  INFO: [T36a79efe] id: 8680180xxxxxxxx, time: 2026-06-04 19:03:20, lat: x.12065, lon: x.95576, course: 210.7, result: SETIO configuration data ok

After that, other positions with answers came with fixtime wrong :

2026-06-04 20:39:13  INFO: [T36a79efe] id: 8680180xxxxxxxx, time: 2026-06-05 00:00:00, lat: x.12065, lon: x.95576, course: 238.2, result: SETIO configuration data ok
2026-06-04 20:42:39  INFO: [T36a79efe] id: 8680180xxxxxxxx, time: 2026-06-05 00:00:00, lat: x.12065, lon: x.95576, course: 238.2, result: SETIO configuration data ok

The device continued sending position packets without issues (and those positions were correctly saved in the database and appeared in reports), but tc_devices.positionid did not update to the latest position. Around 21:45, we were alerted by the user and deleted the positions with the 00:00 fixtime. However, this did not resolve the issue, as tc_devices.positionid remained stuck on the ID of the deleted 00:00 position."

When the device responded to a command, it again reported a position with a 00:00 fixTime. These specific 'answer' position ID was updated in tc_devices.positionid, but the actual, subsequent position updates were ignored and did not update the positionid until this morning.

I have ensured that all future fixTime positions were deleted and have verified that no positions in the database have future timestamps in deviceTime or serverTime.

Thank you.

Anton Tananaev 29 minutes ago

You have to find where the original error came from. The first one. Looking at the latest is pointless because Traccar can copy latest location by time.

RastreameMX 7 minutes ago

Thank you so much, i'll keep doing tests trying to reproduce issue to identify what happened.

About server blocking behaviour on :

2026-06-04 22:07:07  INFO: [T1534350c: h02 < 176.87.x.x] *HQ,xxxxxxxxxx,V1,031451,A,xxxxxx,N,xxxxxx,W,000.00,015,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,031951,A,xxxxxx,N,xxxxxx,W,000.00,015,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,032452,A,xxxxxx,N,xxxxxx,W,000.00,015,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,032952,A,xxxxxx,N,xxxxxx,W,000.00,015,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,033452,A,xxxxxx,N,xxxxxx,W,000.00,015,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,033952,A,xxxxxx,N,xxxxxx,W,000.00,015,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,034453,A,xxxxxx,N,xxxxxx,W,000.00,015,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,034953,A,xxxxxx,N,xxxxxx,W,000.00,015,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,035454,A,xxxxxx,N,xxxxxx,W,000.00,015,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,035954,A,xxxxxx,N,xxxxxx,W,000.00,015,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,040455,A,xxxxxx,N,xxxxxx,W,000.00,015,050626,FBFFFBFF,334,20,28424,62748951#
2026-06-04 22:07:07  INFO: [T1534350c: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: Event id: 7026172196, time: 2026-06-04 22:07:07, type: deviceOnline, notifications: 0
2026-06-04 22:07:07  INFO: [T1534350c: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [T1534350c: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [T1534350c: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [T1534350c: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [T1534350c: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [T1534350c: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [T1534350c: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [T1534350c: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [T1534350c: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [T1534350c: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  WARN: Network forwarding error - Connection refused - ConnectException (... < NetworkForwarder:56 < NetworkForwarderHandler:60 < ...)
2026-06-04 22:07:07  INFO: [Tad5b9f08: h02 < 80.27.x.x] *HQ,xxxxxxxxxx,V1,031703,A,xxxxxx,N,xxxxxx,W,000.00,080,050626,FFFFFBFF,334,03,6365,62220379#
*HQ,xxxxxxxxxx,V1,032204,A,xxxxxx,N,xxxxxx,W,000.00,080,050626,FFFFFBFF,334,03,6365,62220329#
*HQ,xxxxxxxxxx,V1,032705,A,xxxxxx,N,xxxxxx,W,000.00,080,050626,FFFFFBFF,334,03,6365,62220379#
*HQ,xxxxxxxxxx,V1,033207,A,xxxxxx,N,xxxxxx,W,000.00,080,050626,FFFFFBFF,334,03,6365,62220379#
*HQ,xxxxxxxxxx,V1,033707,A,xxxxxx,N,xxxxxx,W,000.00,080,050626,FFFFFBFF,334,03,6365,62220379#
*HQ,xxxxxxxxxx,V1,034207,A,xxxxxx,N,xxxxxx,W,000.00,080,050626,FFFFFBFF,334,03,6365,62220329#
*HQ,xxxxxxxxxx,V1,034708,A,xxxxxx,N,xxxxxx,W,000.00,080,050626,FFFFFBFF,334,03,6365,62220329#
*HQ,xxxxxxxxxx,V1,035209,A,xxxxxx,N,xxxxxx,W,000.00,080,050626,FFFFFBFF,334,03,6365,62220311#
*HQ,xxxxxxxxxx,V1,035711,A,xxxxxx,N,xxxxxx,W,000.00,080,050626,FFFFFBFF,334,03,6365,62220329#
*HQ,xxxxxxxxxx,V1,040211,A,xxxxxx,N,xxxxxx,W,000.00,080,050626,FFFFFBFF,334,03,6365,62220319#
2026-06-04 22:07:07  INFO: [Tad5b9f08: h02 > 80.27.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: Event id: 7026172540, time: 2026-06-04 22:07:07, type: deviceOnline, notifications: 0
2026-06-04 22:07:07  INFO: [Tad5b9f08: h02 > 80.27.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [Tad5b9f08: h02 > 80.27.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [Tad5b9f08: h02 > 80.27.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [Tad5b9f08: h02 > 80.27.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [Tad5b9f08: h02 > 80.27.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [Tad5b9f08: h02 > 80.27.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [Tad5b9f08: h02 > 80.27.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [Tad5b9f08: h02 > 80.27.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  INFO: [Tad5b9f08: h02 > 80.27.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#
2026-06-04 22:07:07  WARN: Network forwarding error - Connection refused - ConnectException (... < NetworkForwarder:56 < NetworkForwarderHandler:60 < ...)
2026-06-04 22:07:07  INFO: [T96232735: h02 < 176.87.x.x] *HQ,xxxxxxxxxx,V1,031436,A,xxxxxx,N,xxxxxx,W,000.00,049,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,031937,A,xxxxxx,N,xxxxxx,W,000.00,049,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,032438,A,xxxxxx,N,xxxxxx,W,000.00,049,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,032938,A,xxxxxx,N,xxxxxx,W,000.00,049,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,033439,A,xxxxxx,N,xxxxxx,W,000.00,049,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,033940,A,xxxxxx,N,xxxxxx,W,000.00,049,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,034440,A,xxxxxx,N,xxxxxx,W,000.00,049,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,034941,A,xxxxxx,N,xxxxxx,W,000.00,049,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,035442,A,xxxxxx,N,xxxxxx,W,000.00,049,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,035942,A,xxxxxx,N,xxxxxx,W,000.00,049,050626,FFFFFBFF,334,20,28424,62748951#
*HQ,xxxxxxxxxx,V1,040442,A,xxxxxx,N,xxxxxx,W,000.00,049,050626,FBFFFBFF,334,20,28424,62748951#
2026-06-04 22:07:07  INFO: [T96232735: h02 > 176.87.x.x] *HQ,xxxxxxxxxx,V4,V1,20260605040707#

Is this expected behavior? It seems as though the server is getting stuck on every forwarding attempt, causing the receiver slots to wait for the forwarder to finish. The whole traccar service works for about 20 seconds, after which the log freezes and only a few devices continue to appear online. Service restarts take about 30 seconds; it then works for another 20 seconds before freezing again.