Unable to Launch New Applications During File Hashing in qBittorrent (Manjaro KDE)

[ling]

I’m using qBittorrent on Manjaro KDE to hash a large file close to 1TB. During the hashing process, the system remains responsive, and existing applications work without any noticeable lag. However, I am unable to launch any new applications (including the terminal). When attempting to open a new application, I receive the following error:

Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Even after pausing the hashing process in qBittorrent, the issue persists, and I still cannot launch new applications.

I have not tried any solutions yet since I cannot open the terminal or access KDE settings. I would appreciate any insights from the community.

---

Known Information

1. System Info: Manjaro KDE
2. qBittorrent Task: Verifying a large file (~1TB). The system itself is responsive during the hashing process.
3. Storage Configuration: The system disk and the disk containing the hashed file are separate.
4. Resource Utilization: CPU usage is around 50% during the process, and there’s no noticeable system lag.

---

Assistance Needed

1. What could be causing this issue? Could it be related to D-Bus, the desktop environment, or disk I/O?
2. How can I troubleshoot or resolve this issue without access to the terminal?
3. If a similar situation occurs in the future, how can I ensure new applications can be launched without interrupting the hashing process?

Thank you for your help!

[ling]

$ neofetch                                                                                                                                                        ✔ 
██████████████████  ████████   ling@ling-20ym 
██████████████████  ████████   -------------- 
██████████████████  ████████   OS: Manjaro Linux x86_64 
██████████████████  ████████   Host: 20YM Lenovo ThinkBook 16p Gen 2 
████████            ████████   Kernel: 6.1.112-1-MANJARO 
████████  ████████  ████████   Uptime: 4 mins 
████████  ████████  ████████   Packages: 1778 (pacman) 
████████  ████████  ████████   Shell: bash 5.2.37 
████████  ████████  ████████   Resolution: 2560x1600, 1920x1080 
████████  ████████  ████████   DE: Plasma 6.1.5 
████████  ████████  ████████   WM: KWin 
████████  ████████  ████████   Theme: [Plasma], Breeze [GTK2/3] 
████████  ████████  ████████   Icons: [Plasma], McMojave-circle-dark [GTK2/3] 
████████  ████████  ████████   Terminal: konsole 
                               CPU: AMD Ryzen 7 5800H with Radeon Graphics (16) @ 3.200GHz 
                               GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series 
                               GPU: NVIDIA GeForce RTX 3060 Mobile / Max-Q 
                               Memory: 7579MiB / 23392MiB

And I have repeated this problem, I found that qBittorrent uses a large amount of system memory cache when verifying files, and it does not release the cache after the verification is complete. As a result, I encountered the aforementioned issue. When the issue occurs, I am unable to execute any new commands or open new applications.

               total        used        free      shared  buff/cache   available
memory：          22Gi       5.6Gi       616Mi        60Mi        17Gi        17Gi
swap：          22Gi       5.8Gi        17Gi

However, after using the following commands to clear the buff/cache, the situation did not improve:

su
systemctl status dbus

And my terminal cannot execute commands like reboot or journalctl -b, showing the error:
Failed to set wall message, ignoring: Connection timed out

[beermad]

I could well imagine that hashing such a large file could take up a lot of memory. So it might be useful to try running free while it’s running. Perhaps open up a separate terminal before you run the hashing and run

while true
do
         free
         sleep 30
done

then watch the output as the hashing progresses.

[ling]

It seems that memory is not the cause of the issue, because after this phenomenon occurred, the situation did not improve after I chose to free up the buff/cache (confirmed by using free to check that buff/cache was released).

[ling]

Everything worked fine after I used this command sudo renice +10 -p $(pgrep qbittorrent) (after a hard reboot, using qbittorrent to recheck the same large file)."

[andreas85]

@ling

after I used this command sudo renice +10 -p $(pgrep qbittorrent)

So qbittorrent is not nice to other programms

Then it would be better to force qbittorrent to always be nice when it is started

[ling]

But I have a question, why does it still occupy these resources or affect the operation of other programs even after the qbittorrent verification is complete?

[andreas85]

@ling

why does it still occupy these resources or affect the operation of other programs even after the qbittorrent verification is complete?

Try to use htop to find out

P.S. With htop you also can renice every process at any time

[Aragorn]

@ling

why does it still occupy these resources or affect the operation of other programs even after the qbittorrent verification is complete?

Because I/O is an uninterruptible process.

[fredvej]

I also had problems with qBittorrent using too much RAM and making the system unresponsive. I limit the amount of RAM that qBittorrent can use with this:

mkdir --parent ~/.config/systemd/user/app-org.qbittorrent.qBittorrent@.service.d
printf %b '[Service]\nMemoryAccounting=yes\nMemoryHigh=12G\n' > ~/.config/systemd/user/app-org.qbittorrent.qBittorrent@.service.d/memhi.conf

(My PC has 16 GB RAM)

[scotty65]

@fredvej

I also had problems with qBittorrent using too much RAM and making the system unresponsive. I limit the amount of RAM that qBittorrent can use with this

I’m glad the How to Limit Application Memory Usage with systemd - KDE Blogs topic I posted in the Member Hub a month ago has found a real-world use.

For those members who haven’t yet reached the forum trust level where they can access the Member Hub, here’s the original article:

Limit Application Memory Usage with systemd