Device information
-
Model: RUTC50
-
Firmware: RUTX_R_00.07.23.7 (RutOS)
-
Total RAM: 496,304 KB
Team,
After a certain uptime (originally ~20–24 hours, see below), the device becomes progressively slower to respond via WebUI, and eventually becomes completely unresponsive — both the WebUI and SSH (dropbear) stop responding — requiring a hard power cycle (AC off/on) to recover. A graceful reboot via WebUI/CLI is sometimes still possible shortly before the hang, but not reliably.
Through several days of monitoring (via SSH, free, /proc/[pid]/status, and the router’s own troubleshoot/diagnostic export), we traced this to continuous, unbounded growth of the /usr/sbin/session process (RSS memory), which we were able to correlate directly with the file /tmp/session-ips growing without limit.
Root cause identified
/tmp/session-ips appears to log one line per authenticated session (session hash + source IP), for both WebUI logins and REST API (/api/login) authentications. Critically:
-
Every line in this file is unique — no entries are ever removed, regardless of whether the corresponding session has since logged out, or whether the associated API token (which we confirmed expires after 5 minutes) has expired long ago.
-
This file lives in
/tmp(tmpfs), so it resets on reboot — but grows continuously and indefinitely for the entire uptime otherwise. -
The
/usr/sbin/sessionprocess’s RSS memory grows in close correlation with this file’s line count.
Diagnostic timeline / data
We initially suspected our own automation (a Python script polling the REST API every few minutes, plus Home Assistant’s native RUTX/RUTC integration, plus WebUI logins) as the primary cause, since all of these repeatedly authenticate against the device. We tested this hypothesis in stages:
| Phase | Approx. growth rate (used memory) |
Configuration |
|---|---|---|
| Original (unmodified) | ~150–390+ KB/min, accelerating over time | Custom script logging in fresh on every poll (no token reuse) + native HA integration polling + occasional WebUI logins |
| After adding client-side token caching to our script (reusing the API token until shortly before its 5-minute expiry, instead of logging in on every poll) | ~17–55 KB/min | Native integration still active |
| After also disabling the native polling integration | ~26 KB/min, very stable/linear | Only our own script remains, authenticating no more often than once per 5-minute token lifetime |
At the final stage, /tmp/session-ips grew at almost exactly one new line every ~5 minutes — i.e., precisely matching the API token’s expiry interval, with all traffic originating from a single, well-behaved client that only re-authenticates when its cached token has actually expired.
This is the key finding we’d like to highlight: growth did not stop even when the client-side behavior was reduced to the theoretical minimum (one authentication per token lifetime, with no overlapping/duplicate logins). This points to a lack of session cleanup/expiry logic on the device side, rather than a client misbehavior issue.
Full memory exhaustion event (for reference)
Before the above mitigations were in place, we captured the full progression to a hang, via repeated free snapshots:
| Time | Available memory | Notes |
|---|---|---|
| T+0h (reboot) | 329,688 KB (66%) | Baseline after reboot |
| T+~20h | ~46,000–61,000 KB (~10–12%) | WebUI login noticeably slower |
| T+~22h | 15,576 KB (3.1%) | WebUI login very slow |
| T+~23h | 700 KB (0.14%) | Device became completely unresponsive — WebUI and SSH both stopped responding. Required hard power cycle to recover. |
Questions for Teltonika support
-
Is this a known issue with the
sessionservice //tmp/session-ipsnot expiring or pruning old entries? -
Is there a documented
/api/logoutendpoint (or equivalent) that properly invalidates a session server-side after use? We were unable to find one in the public API documentation. -
Is there a configurable session/idle timeout or cleanup mechanism (via UCI or otherwise) that we could enable to prevent this file/process from growing indefinitely?
-
Is a fix planned in an upcoming firmware release?
Workaround currently in place
As a mitigation, we’ve configured a daily scheduled reboot via the built-in Reboot Scheduler, and reduced our own polling to the minimum necessary frequency. This keeps the device well within safe memory bounds, but we would prefer a proper fix rather than relying on a workaround.
Happy to provide the full troubleshoot export, SSH session logs, or any further diagnostic data if helpful.
Peter