# Memory Leak in RUTM52 with RUTM\_R\_00.07.24.1 **URL:** \ **Category:** Issue\ **Created:** [July 28, 2026, 8:48am UTC](https://community.teltonika.lt/t/memory-leak-in-rutm52-with-rutm-r-00-07-24-1/20400 "2026-07-28T08:48:35Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![JDIN](https://community.teltonika.lt/letter_avatar_proxy/v4/letter/j/9d8465/32.png) [@JDIN](https://community.teltonika.lt/u/JDIN)\ **Post date:** [July 28, 2026, 8:48am UTC](https://community.teltonika.lt/t/memory-leak-in-rutm52-with-rutm-r-00-07-24-1/20400/1 "2026-07-28T08:48:35Z")
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: ```auto POST /api/login ``` 1. Store the returned Bearer token. 2. Periodically query: ```auto 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: ```auto 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 ---
**Author:** ![Justinas](https://community.teltonika.lt/user_avatar/community.teltonika.lt/justinas/32/17132_2.png) [@Justinas](https://community.teltonika.lt/u/Justinas)\ **Post date:** [July 31, 2026, 9:02pm UTC](https://community.teltonika.lt/t/memory-leak-in-rutm52-with-rutm-r-00-07-24-1/20400/3 "2026-07-31T21:02:40Z")
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 ---
**Author:** ![Justinas](https://community.teltonika.lt/user_avatar/community.teltonika.lt/justinas/32/17132_2.png) [@Justinas](https://community.teltonika.lt/u/Justinas)\ **Post date:** [August 4, 2026, 8:05am UTC](https://community.teltonika.lt/t/memory-leak-in-rutm52-with-rutm-r-00-07-24-1/20400/4 "2026-08-04T08:05:26Z")
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