qBittorrent container 4.6.3 have problem in some arm64 platforms

Hello,

I deploy qBittorrent container to ASUSTOR arm64 NAS for a long time without any problem.
But, from 4.6.3, I got the followings error. I cannot identify what’s going on from the errors!
Can anyone help for checking?

[custom-init] No custom files found, skipping…
crond[150]: crond (busybox 1.36.1) started, log level 5
QIODevice::seek (QFile, “/config/qBittorrent/logs/qbittorrent.log”): Cannot call seek on a sequential device
WebUI will be started shortly after internal preparations. Please wait…
qt.core.plugin.loader: /usr/lib/qt6/plugins/tls/libqcertonlybackend.so: failed to map to memory: Invalid argument
qt.core.plugin.loader: /usr/lib/qt6/plugins/tls/libqopensslbackend.so: failed to map to memory: Invalid argument
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No TLS backend is available
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No TLS backend is available
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No TLS backend is available
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No TLS backend is available
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: QSslSocket::connectToHostEncrypted: TLS initialization failed
qt.network.ssl: No functional TLS backend was found

Thanks!

I had this problem since 4.6.4 update on my Drivestor2. The culprits are the 2 qt6-qtbase packages, one of the latest release broke my setup. I had to start from an old image (latest working for me was linuxserver/qbittorrent:4.6.3) and manually update everything but the 2 qt6-qtbase packages.
I’ve posted the workaround on the asustor reddit sub, if you need a step by step guide.

This was bound to happen to web apps eventually. We have been dealing with this on the desktop app side for many years by telling folks to set " --security-opt seccomp=unconfined"
As your device ages it never gets software upgrades, eventually the software that is running in a modern distro in the docker container will make syscalls that seccomp filters or cannot translate properly.
Out of curiosity what is the kernel version on these things?

Update the version information.
4.6.3 works on arm64 platform, but 4.6.4 failed.
Not change any kernel or app configuration, only pull different image tag,
but the container will get the errors with 4.6.4 image.

Mine is on 4.9.119, pretty old for a device that is not on EOS
So you’re thinking that is a kernel issue?

More libseccomp, does seccomp unconfined work?

I’ve no experience with custom parameters with docker so myabe I’ve made some mistake, I’ve recreated the container in this way:

docker run -d --security-opt seccomp=unconfined \
  --name=qbittorrent_seccomp \ [rest of the configuration]

but with same errors as before:

[custom-init] No custom files found, skipping...
QIODevice::seek (QFile, "/config/qBittorrent/logs/qbittorrent.log"): Cannot call seek on a sequential device
WebUI will be started shortly after internal preparations. Please wait...
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
QIODevice::seek (QFile, "/config/qBittorrent/logs/qbittorrent.log"): Cannot call seek on a sequential device
WebUI will be started shortly after internal preparations. Please wait...
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
QIODevice::seek (QFile, "/config/qBittorrent/logs/qbittorrent.log"): Cannot call seek on a sequential device
WebUI will be started shortly after internal preparations. Please wait...
qt.core.plugin.loader: /usr/lib/qt6/plugins/tls/libqcertonlybackend.so: failed to map to memory: Invalid argument
qt.core.plugin.loader: /usr/lib/qt6/plugins/tls/libqopensslbackend.so: failed to map to memory: Invalid argument
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found
qt.network.ssl: No functional TLS backend was found

The issue started with qt6-qtbase/sqlite 6.6.2-r1, if I force 6.6.2-r0 and update all other packages, including qbit, it works fine

Thanks for trying seccomp, so looking at your error and going over this thread ape mmap fails on embedded devices whose linux kernels are configured to have <48bit address space · Issue #74 · Mozilla-Ocho/llamafile · GitHub, it looks like an mmap call is failing. I can’t tell you with certainty but it seems like this may be in the same boat.
You would have to engage with qt/Asus directly or figure out a way to not run their custom kernel.

1 Like