Note: this was reproduced using the native rclone internxt backend
(github.com/internxt/rclone), invoked directly via a standalone rclone
binary — not via the internxt-cli tool itself. Filing here since the
internxt/rclone repository does not have issues enabled; please redirect
if there's a better place for backend-specific reports.
Summary
When syncing a large number of image files (JPG) to Internxt Drive via the native
rclone internxt backend, process memory grows continuously and is never released.
On a container with 4 GiB RAM, the process is killed by the OOM killer after roughly
200–250 newly uploaded JPEGs (each ~3–4 MB), which corresponds to ~14–17 MB of
retained memory per processed image. Growth rate correlates with the number of
images processed per unit time, not with elapsed time or total bytes transferred.
Environment
- rclone version: v1.75.0 (native
internxt backend, available since v1.73) - OS: Debian 13, inside an unprivileged Proxmox LXC container
- Backend config: defaults (
upload_concurrency=4, chunk_size=30Mi,
upload_cutoff=100Mi). All affected files are well below the multipart
cutoff, so chunk buffering does not explain the growth. - Command:
rclone sync /local/path internxt:Backup/path -v --stats 10s - Reproduced at both 4 GiB and 2 GiB container memory (only the time-to-OOM differs)
Observed behavior
- Debug logs show a
[DEBUG] Uploading thumbnail for file <uuid> line for every
newly uploaded image, in addition to the normal Copied (new) line. - Process RSS (
/proc/<pid>/status → VmRSS), sampled every 5s, climbs steadily
and monotonically while syncing directories with many JPEGs, e.g.:
22:16:29 507 MB
22:16:54 1247 MB
22:17:34 1858 MB
22:18:14 2943 MB
22:18:34 4062 MB <- OOM-killed at ~4074 MB (cgroup limit)
- Growth stalls when the sync passes through directories with few/no images
(PDF, DOCX, etc.) and resumes at the same rate once it re-enters an
image-heavy directory — strongly correlated with image count, not time. - Files already present at the destination (skipped via
Duplicate object found in destination - ignoring) do not trigger the
thumbnail log line and do not contribute to the growth — this narrows the
leak specifically to the newly-uploaded-image / thumbnail code path, rather
than directory listing or general sync bookkeeping. - Host kernel log confirms a genuine cgroup OOM kill of the
rclone process
itself (not the container generally), anon-rss: ~4.1 GiB at time of kill
(attached).
Expected behavior
Memory used for thumbnail generation/upload per file should be released once
that file's upload completes, keeping steady-state memory roughly constant
regardless of how many images have been processed in a run.
Steps to reproduce
- Configure a native
internxt remote (rclone config, type internxt) rclone sync <folder with several thousand JPEGs, several MB each> internxt:<dest> -v --stats 10s- Monitor
VmRSS of the rclone process while it runs - Observe steady, monotonic growth of several MB per processed image; eventual OOM
Attached
sync-tail-500.txt — verbose log excerpt covering the crash windowrss-timeline.log — VmRSS samples every 5s across the runoom-dmesg.txt — host kernel log confirming the cgroup OOM kill
Happy to provide further diagnostics if useful (e.g. a Go heap profile via
/debug/pprof/heap from the running rcd — not yet collected).
sync-tail-500.txt
rss-timeline-full.txt
oom-dmesg.txt
Summary
When syncing a large number of image files (JPG) to Internxt Drive via the native
rclone
internxtbackend, process memory grows continuously and is never released.On a container with 4 GiB RAM, the process is killed by the OOM killer after roughly
200–250 newly uploaded JPEGs (each ~3–4 MB), which corresponds to ~14–17 MB of
retained memory per processed image. Growth rate correlates with the number of
images processed per unit time, not with elapsed time or total bytes transferred.
Environment
internxtbackend, available since v1.73)upload_concurrency=4,chunk_size=30Mi,upload_cutoff=100Mi). All affected files are well below the multipartcutoff, so chunk buffering does not explain the growth.
rclone sync /local/path internxt:Backup/path -v --stats 10sObserved behavior
[DEBUG] Uploading thumbnail for file <uuid>line for everynewly uploaded image, in addition to the normal
Copied (new)line./proc/<pid>/status→VmRSS), sampled every 5s, climbs steadilyand monotonically while syncing directories with many JPEGs, e.g.:
22:16:29 507 MB
22:16:54 1247 MB
22:17:34 1858 MB
22:18:14 2943 MB
22:18:34 4062 MB <- OOM-killed at ~4074 MB (cgroup limit)
(PDF, DOCX, etc.) and resumes at the same rate once it re-enters an
image-heavy directory — strongly correlated with image count, not time.
Duplicate object found in destination - ignoring) do not trigger thethumbnail log line and do not contribute to the growth — this narrows the
leak specifically to the newly-uploaded-image / thumbnail code path, rather
than directory listing or general sync bookkeeping.
rcloneprocessitself (not the container generally),
anon-rss: ~4.1 GiBat time of kill(attached).
Expected behavior
Memory used for thumbnail generation/upload per file should be released once
that file's upload completes, keeping steady-state memory roughly constant
regardless of how many images have been processed in a run.
Steps to reproduce
internxtremote (rclone config, typeinternxt)rclone sync <folder with several thousand JPEGs, several MB each> internxt:<dest> -v --stats 10sVmRSSof the rclone process while it runsAttached
sync-tail-500.txt— verbose log excerpt covering the crash windowrss-timeline.log— VmRSS samples every 5s across the runoom-dmesg.txt— host kernel log confirming the cgroup OOM killHappy to provide further diagnostics if useful (e.g. a Go heap profile via
/debug/pprof/heapfrom the runningrcd— not yet collected).sync-tail-500.txt
rss-timeline-full.txt
oom-dmesg.txt