Memory Leak in RUTM52 with RUTM_R_00.07.24.1

Networking Solutions Issue
1

Dear Teltonika Support,

we have observed what appears to be a memory leak in the RutOS session process on a RUTM52 router when the REST API is queried periodically. As we use the router with tailscale vpn this leads after two days in completely unresponsive admin ui and connection being dropped to tailscale as the system seems to hard stop the tailscale service.

Test Environment

A Python-based Docker service polls the router every 10 seconds to retrieve the current WAN status.

The communication sequence is as follows:

  1. Authenticate via:
POST /api/login

  1. Store the returned Bearer token.

  2. Periodically query:

GET /api/ip_routes/ipv4/status

The application uses a single persistent requests.Session() object. A new HTTP session is not created for every request.

The Bearer token is cached for 240 seconds and reused for all API requests during that period. A new login is only performed after the token expires or when the router returns HTTP 401/403. Therefore, the router is not being authenticated every 10 seconds.

Observed Behavior

While the Docker service is running, the memory usage of the RutOS session process continuously increases.

Measured values:

Tue Jul 28 07:34:03 UTC 2026
VmRSS:      1060 kB
RssAnon:     208 kB

Tue Jul 28 07:39:03 UTC 2026
VmRSS:      1108 kB
RssAnon:     256 kB

Tue Jul 28 07:44:03 UTC 2026
VmRSS:      1160 kB
RssAnon:     308 kB

Tue Jul 28 07:49:03 UTC 2026
VmRSS:      1208 kB
RssAnon:     356 kB

Tue Jul 28 07:54:03 UTC 2026
VmRSS:      1292 kB
RssAnon:     440 kB

Tue Jul 28 07:59:04 UTC 2026
VmRSS:      1340 kB
RssAnon:     488 kB

Tue Jul 28 08:04:04 UTC 2026
VmRSS:      1400 kB
RssAnon:     548 kB

Tue Jul 28 08:09:04 UTC 2026
VmRSS:      1440 kB
RssAnon:     588 kB

Tue Jul 28 08:14:04 UTC 2026
VmRSS:      1528 kB
RssAnon:     676 kB

Tue Jul 28 08:19:04 UTC 2026
VmRSS:      1588 kB
RssAnon:     736 kB

Within only 45 minutes, RssAnon increased from 208 kB to 736 kB, corresponding to approximately:

  • 528 kB in 45 minutes

  • ~700 kB per hour

  • ~16–17 MB per day

During the entire observation period, memory usage increased continuously and never stabilized or decreased.

Verification Test

To verify the source of the problem, we completely stopped the Docker service.

After stopping the service, the memory usage of the RutOS session process remained completely stable for more than 60 minutes. No further increase was observed.

This strongly indicates that the repeated REST API requests trigger the increasing memory consumption inside the router’s session process.

Our Current Assessment

From our perspective, one of the following may be happening:

  • API sessions or Bearer tokens are not completely released after re-authentication.

  • The endpoint /api/ip_routes/ipv4/status allocates memory that is not released.

  • Internal resources associated with authenticated REST API requests are not cleaned up correctly.

Since the increasing memory usage is observed inside the router’s own session process, and not in the external Python application, we believe this may be a memory leak within RutOS itself.

Questions

  1. Is this behavior already known for the RUTM52 or the current RutOS version?

  2. Are there any known memory leaks related to the session process or the REST API?

  3. Are expired Bearer tokens automatically cleaned up by RutOS?

  4. Is there a recommended lifetime or reuse strategy for REST API tokens?

  5. Are there any known issues with frequent requests to /api/ip_routes/ipv4/status?

  6. Is this issue fixed in a newer RutOS release, or is there a recommended workaround?

Device Information

  • Device: Teltonika RUTM52

  • RutOS Version: RUTM_R_00.07.23.8

  • API polling interval: 10 seconds

  • Bearer token lifetime in our application: 240 seconds

3

Greetings,

Could you please clarify which firmware version you are using? In the title, you mention version 7.24.1, while in the post itself you mention 7.23.8. Is the issue occurring on both versions? Did this previously work fine on any other FW versions?

Have you made any changes to the /etc/config/vuci file? If so, did you modify only the api_session_timeout value, or did you also change the session_timeout value?

I didn’t have a RUTM52 available, so I recreated your setup on a RUTX14 running firmware version 7.24.1.

During testing, I observed that the session process size increases and API sessions are not closed (ubus call session list | grep ubus_rpc_session | wc -l can be used to check how many sessions are active), even after the session tokens have expired. However, everything is reset once the time configured in the session_timeout value has elapsed. By default, this is set to 30 minutes.

I’m not sure whether this is the intended behavior, so I will consult with our R&D team for clarification.

I also plan to test this on a RUTM52 next week.

Best regards,
Justinas

4

Greetings,

In my last reply I was mistaken regarding the session_timeout value, that only controls the WebUI session timeout. During testing I had the WebUI open and that caused the sessions to reset after 30 minutes.

Upon further testing I recreated the issues you are having and have forwarded the case to our R&D department. Once I get their feedback, I will get back to you.

Best Regards,
Justinas