Warning: Update to dragonfish broke qBittorrent docker

I’ve been running this image for 2 years: GitHub - binhex/arch-qbittorrentvpn: Docker build script for Arch Linux base with qBittorrent, Privoxy and OpenVPN because of the WireGuard support.
It simply does not run correctly on dragonfish. it is very slow and eventually freezes or crashes. download speeds are at 1Mbps vs 100MBps I have usually.

Here is what i have tried to fix it:

  • reset all settings (option 5)
  • full reinstall of apps with new app pool
  • full clean reinstall of OS, import settings
  • full clean reinstall of OS, with no import of settings
  • change container image to: hotio/qbittorrent - hotio.dev
  • run a ramtest
  • delete 18000 torrents and start from 0

All of this did not work, still slow and freezing after 30min killing the NAS, so I went one step further: I set up a ubuntu VM on truenas, mount storage with NFS, installed docker, and ran the same qbittorent image.

Same issue. htop shows no high cpu/ram/storage usage, same for htop inside of the container. nothing special. logs shows nothing. No Truenas ui warnings

So after a few days, desperate I re-installed cobia, redeployed the image and… it just runs, great performance, great ui responsiveness.

This is 100% a dragonfish OS issue. I suspect it is storage related as it is an IO heavy app and it slows to a crawl. Pretty bad for a NAS OS… All other apps run fine.

So here is my warning if you run qBittorent, don’t upgrade, you won’t be able to fix it.

I would make a ticket but with no logs good luck, way to repro is to just deploy the above images, load some torrents and see how it runs. Do the same on Cobia and compare.

I’m on dragonfish and my qbittorrent app from truecharts runs just fine with max download speed. Just tried with a manjaro linux iso… I currently have no vpn set up so can’t test if it’s maybe vpn related…

OP does not seem to be using truecharts as far as I understand.

IMO warning users that all versions (his title of the post) of qbittorrent don’t work if his particular version of qbittorrent doesn’t work is kind of exaggerated. Hence my comment that other versions work on dragonfish.

Very much so.

1 Like

Updated the title to hopefully better illustrate the situation.

Are you’re system swapping since Dragonfish with qbittorrent ?

Since dragonfish ZFS ARC is not limited to 50% of memory usage like before, for me this resulted in heavy swap usage after 24H of uptime. I had to set a limit for ZFS cache to 50% of my total RAM like before the upgrade to make everything work again as expected, no more swap, no more WebUI unresponsive etc.


That’s not how things should work.

I know, but for me this is the only way i found to recover a normal usage of my NAS and my Apps …

Non limited ZFS cache worked fine in Core for me, but not with Dragonfish :confused:

Get a look : Swap since dragonfish upgrade - #2 by Noks

1 Like

In your qBittorrent web UI, go to Help → About → Software Used

Here is mine for reference on TrueNAS Core, within a FreeBSD jail based on 13.2-RELEASE:

What is the version of libtorrent-rasterbar for your App?

qBittorrent packaged for FreeBSD uses libtorrent version 1.2.x by default.

Linux distros, including maintainers for containers, TrueCharts, iXsystems, etc, likely compile it for libtorrent 2.x, which was known (and still is known?) to cause issues with ZFS/ARC.

If so, you might be able to submit a request to TrueCharts or iXsystems (or whomever) to include a version of the qBittorrent app compiled against libtorrent 1.2.x.

EDIT: Fun fact. Even upstream qBittorrent offers their application built for libtorrent 1.2.x as the default download. If you want it with libtorrent 2.x? You have to purposefully choose the lt20 binary from the download options.

EDIT 2: One thing you can try in the meantime is to set a maximum RAM usage for your qBittorrent instance, which is a parameter used by libtorrent 2.x.

Go to Tools → Options → Advanced, then set “Physical memory usage limit” to a sane value. (This option is ignored if you’re using libtorrent 1.2.x.) By capping libtorrent’s memory usage, you might be able to (temporarily) postpone your issue with heavy swapping and system slowdowns.

As for aggressively swapping memory to disk? This was one of my concerns with “tweaking” SCALE’s parameters (Linux) to allow for a higher ARC ceiling. I remember iXsystems claiming there were no issues in their testing. But I’m just enjoying life on TrueNAS Core (FreeBSD) while it’s still being supported for now. :wink:


Qbittorrent from Truecharts seem’s to be with libtorrent 1.2.x by default, this is my case, so the issue is not here for me.

Do i realy need a lot of ZFS Cache ? Dosent seem’s to me, until i’ve restored the 50% cap for ZFS Cache i have no issue at all.

But yes, if i understand it correctly, ZFS cache should release some RAM in response to system need, i don’t understand why the system is swapping when ARC is not limited to 50% of the RAM … In fact, with CORE this worked correctly witouth tweaking anything.

1 Like

Eh, the joke lurking around here is that Linux’s Kernel writers should learn a thing or two regarding RAM/ARC management.


Yep it seem so


I’ve been going mad for two days now! middlewared crashes, extremely slow system, my only vm literally stopping …

I solved it by limiting to 32GB (half of my ram), putting the following code in the Init Scripts

echo 34359738368 >> /sys/module/zfs/parameters/zfs_arc_max
1 Like

Lookie lookie what I found. :grin:

First this.

And then this.

In other words, maybe the concerns remain (even today), and these real-world examples mean it’s not truly on par with FreeBSD?

1 Like

Exactly same for me. Since Dragonfish, Truena is going to swap 1.4 gb in 24H uptime resulting in unresponsive WebUI. As you, i solved this by settings the ARC limit at half my total RAM …

1 Like

It seem so.

But for me it’s not a big deal if i can’t use max memory for ZFS cache. I just don’t understand why Ix have pushed this new limit when we see this behavior in real world :confused:

Because one of ZFS’s greatest features, which end-users will notice day-to-day, is the ARC. Sheer performance gains, whether data or metadata, and less stress on the storage devices.

FreeBSD’s memory management works seamlessly with the ZFS ARC.

Linux on the other hand? No so much. Hence, why it is limited to 50% of available physical RAM: to prevent such issues as you are experiencing. (Default set by upstream OpenZFS on Linux.)

But it’s such a shame that the ARC is being arbitrarily limited to 50% of RAM, in which it can shine without any restrictions (as evidenced by FreeBSD.) What’s the solution for Linux? Tweak a parameter to allow the ARC to use up as much memory as is needed, just like on FreeBSD! :partying_face:

And now you see that at the end of the day, it’s still inferior to ZFS on FreeBSD.

But don’t worry. SCALE’s got “Apps” and K3s and TrueCharts. :+1: And don’t forget, Linux is “super cool”.

But yes, i love Linux for many aspects. Ok ZFS seem to not work as good as FreeBSD in regards of ARC. But like i said, it’s not a big deal for me in my use case.

Every system have their pros and cons, Linux kernel didn’t become shit juste because of this ZFS behavior man … And FreeBSD didn’t become shit just because they don’t have K3s or whatever. It’s just matter of needs, use case, personal preferences etc etc.

I couldn’t agree more! :clap:

That’s why iXsystems is going to develop and maintain two versions of TrueNAS: Core and SCALE