Opened 6 years ago

Last modified 3 weeks ago

#3165 new bug

"Device or resource busy" on Linux kernel newer than 4.9.0-3

Reported by: siddhartha Owned by:
Priority: critical Milestone: needs verified
Component: Core Version: 1.3.15
Keywords: kernel, device or resource busy Cc:



This bug affects all versions of Deluge up to and including 2.0 Beta 1.


A VMWare ESXi 6.5 server hosts a Debian Stretch VM running Deluge 1.3.15 (deluged). The ESXi server connects to a datastore on a NAS over NFS running OpenMediaVault where the VM files are stored. The Debian VM mounts a directory on the same OpenMediaVault NAS over NFS for downloading torrents.


Large 5+ GB torrents will fail with "Device or resource busy" when downloading at high 2+ MiB/s speeds. This only started after updating to the latest stable Linux kernel for Debian Stretch (linux-image-4.9.0-6-amd64).


On the Debian VM (deluged), I wanted to first eliminate the kernel as the source, so I installed the latest version from sid, linux-image-4.15.0-1-amd64.

My test torrent was an 11 GB copy of SWTLJ, so it had thousands of seeds. Using deluge 1.3.15, the download speed got up to around 4 MiB/s after less than 20 seconds and then immediately failed with "Device or resource busy".

Without restarting and using the same 4.15.0-1 kernel, I installed qBittorrent 3.3.7 (qbittorrent-nox) and setup that daemon to use the same user as the Deluge daemon. I also pointed qBittorrent to download to the same NFS mount as Deluge. The settings were as close as possible for network, bandwidth, and queue, including the number of global and per-torrent connections. With qBittorrent, download speeds got up to just over 8 MiB/s, averaging at 6 MiB/s and the entire torrent downloaded without issue.

Both deluged and qbittorrent-nox had roughly the same CPU usage at above 65%.

Since I was using the same VM with the same kernel with the same user on the same NFS mount and qBittorrent also uses libtorrent, I think it's safe to conclude that the error is unique to Deluge. What's frustrating is that downgrading the kernel to 4.9.0-3 solves the problem.


Here is a thread related to this bug. One user found that mounting the download directory over SMB instead of NFS solved the problem.

Change History (2)

comment:1 by siddhartha, 6 years ago

For reference, I am running:

  • libboost-python1.62.0 1.62.0+dfsg-4
  • libtorrent-rasterbar9 1.1.5-1
  • python-libtorrent 1.1.5-1

comment:2 by siddhartha, 6 years ago

I compiled libtorrent 1.1.6 and 1.2.0 from source and still no love.

Last edited 6 years ago by siddhartha (previous) (diff)
Note: See TracTickets for help on using tickets.