-
What's your question or issue?I'm trying to setup a new instance of Paperless NGX, and import around 120 PDFs. The Container is running on my Unraid server, with access to 32gb of ram and 16cpu cores When I restart the server with documents in the Consumption folder they are discovered but the majority of them almost instantly fail with this error message: 24 Docs have imported successfully, and sometimes when I restart the container a few more will import sucessfully. All of these docs were exported as originals from a very old Paperless NG Instance (I'm not upgrading for a few reasons, fresh start is desired) The Files vary from 151kb to max 16mb, and all imported to PaperlessNG on the same Host OS without issues. What have you tried?I've added a bunch of the flags meant to help with resource issues already, but with little benefit I can see. PAPERLESS_TASK_WORKERS: 1 PAPERLESS_CONVERT_MEMORY_LIMIT: 128 PAPERLESS_CONVERT_TMPDIR: - /mnt/user/Docker_Data/Paperless-NGX/Temp I have tried with unlimited Ram access, and a dedicated 2gb with the --memory=2G I have tried with unlimited core access, and a dedicated 4 Paperless-ngx versionv2.20.15 Host OSUnraid 7.0.1 Installation methodDocker - official image System status{
"pngx_version": "2.20.15",
"server_os": "Linux-6.6.78-Unraid-x86_64-with-glibc2.41",
"install_type": "docker",
"storage": {
"total": 26593341440000,
"available": 8543216672768
},
"database": {
"type": "sqlite",
"url": "/usr/src/paperless/data/db.sqlite3",
"status": "OK",
"error": null,
"migration_status": {
"latest_migration": "paperless_mail.0001_initial_squashed_0009_mailrule_assign_tags",
"unapplied_migrations": []
}
},
"tasks": {
"redis_url": "redis://192.168.0.100:6379",
"redis_status": "OK",
"redis_error": null,
"celery_status": "OK",
"celery_url": "celery@ee217ef0cf6a",
"celery_error": null,
"index_status": "OK",
"index_last_modified": "2026-07-17T09:14:11.785956+01:00",
"index_error": null,
"classifier_status": "OK",
"classifier_last_trained": "2026-07-17T08:05:04.788073Z",
"classifier_error": null,
"sanity_check_status": "OK",
"sanity_check_last_run": "2026-07-17T08:20:39.874630Z",
"sanity_check_error": null
},
"websocket_connected": "OK"
}Relevant logs or outputRedis Logs:
1:M 17 Jul 2026 09:11:14.065 * 100 changes in 300 seconds. Saving...
1:M 17 Jul 2026 09:11:14.066 * Background saving started by pid 134
134:C 17 Jul 2026 09:11:14.075 * BGSAVE done, 11 keys saved, 0 keys skipped, 30733 bytes written.
134:C 17 Jul 2026 09:11:14.084 * DB saved on disk
134:C 17 Jul 2026 09:11:14.086 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB
1:M 17 Jul 2026 09:11:14.168 * Background saving terminated with success
1:M 17 Jul 2026 09:16:15.070 * 100 changes in 300 seconds. Saving...
1:M 17 Jul 2026 09:16:15.072 * Background saving started by pid 135
135:C 17 Jul 2026 09:16:15.081 * BGSAVE done, 27 keys saved, 0 keys skipped, 112740 bytes written.
135:C 17 Jul 2026 09:16:15.091 * DB saved on disk
135:C 17 Jul 2026 09:16:15.093 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 1 MB
1:M 17 Jul 2026 09:16:15.173 * Background saving terminated with success |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments
-
|
Signal 4 is To narrow it down, can you run these on the Unraid host (not inside the container), the first one right after some failures? dmesg -T | grep -i 'trap invalid opcode'
grep -m1 'model name' /proc/cpuinfo
grep -o -m1 avx2 /proc/cpuinfoThe first prints the library that actually faulted, which should tell us where to look. Also, when a document fails and you restart, does that same document fail again, or does it vary? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your reply! Result from commands: dmesg -T | grep -i 'trap invalid opcode' model name : AMD Opteron(tm) Processor 4386 3rd command didn't return an output, so no Advanced Vector Extensions 2 support on my CPU. Different documents complete when I re-run. This time 2 more succussed, but the remainder failed. |
Beta Was this translation helpful? Give feedback.
-
|
All five crashes fault at the same offset in Your CPU (AMD Opteron 4386, Piledriver, no AVX2) has known CPUID quirks that can trick glibc's ifunc resolver into picking an AVX2 code path anyway, which would also explain why it's nondeterministic. Try forcing glibc to skip that path: Set that as a container env var and restart. Should be a glibc/CPU-detection issue, not something fixable in paperless-ngx itself. (Note: I used Claude to help investigate and draft this suggestion, worth confirming it actually resolves it before treating it as settled.) |
Beta Was this translation helpful? Give feedback.
-
|
Threw that flag into the container, and rebooted. Worked like a charm. Thanks so much, deeply appreciated! |
Beta Was this translation helpful? Give feedback.
-
|
This discussion has been automatically closed because it was marked as answered. Please see our contributing guidelines for more details. |
Beta Was this translation helpful? Give feedback.
All five crashes fault at the same offset in
libm.so.6, so this looks like a single glibc math routine (likelyexp/log/pow, used by numpy/scikit-learn), not paperless-ngx code.Your CPU (AMD Opteron 4386, Piledriver, no AVX2) has known CPUID quirks that can trick glibc's ifunc resolver into picking an AVX2 code path anyway, which would also explain why it's nondeterministic.
Try forcing glibc to skip that path:
Set that as a container env var and restart. Should be a glibc/CPU-detection issue, not something fixable in paperless-ngx itself.
(Note: I used Claude to help investigate and draft this suggestion, worth confirming it actually r…