uTorrent fails with "too many open files"

[joncage]

I have a virtualbox running Ubuntu (Kosmic Koala) with a Windows XP SP3 guest.

I'm trying to run uTorrent on the guest O/S and it's fine to begin with - torrents start okay but sometimes immediately and sometimes after a few hours it pops up saying "Error: The parameter is incorrect".

I've checked the virtualbox logs and see quite a few entries like this:

207:50:46.297 SharedFolders host service: Cannot open '/drv/software/ubuntu-9.10-desktop-i386/~uTorrentPartFile_15DC5000.dat' -- too many open files.
207:50:46.298 SharedFolders host service: Cannot open '/drv/software/ubuntu-9.10-desktop-i386/~uTorrentPartFile_15DC5000.dat' -- too many open files.
207:50:48.247 SharedFolders host service: Cannot open '/drv/software/ubuntu-9.10-desktop-i386/~uTorrentPartFile_15DC5000.dat' -- too many open files.
207:50:48.248 SharedFolders host service: Cannot open '/drv/software/ubuntu-9.10-desktop-i386/~uTorrentPartFile_15DC5000.dat' -- too many open files.
207:50:49.280 SharedFolders host service: Cannot open '/drv/software/ubuntu-9.10-desktop-i386/~uTorrentPartFile_15DC5000.dat' -- too many open files.
207:50:49.281 SharedFolders host service: Cannot open '/drv/software/ubuntu-9.10-desktop-i386/~uTorrentPartFile_15DC5000.dat' -- too many open files.

shutting down the virtualbox service and re-starting it normally does the trick if the guest is shut down first. I use the server to host software I write so having to go in and reboot all the time is (as you might imagine) rather frustrating!

I noticed one log entry suggested running "ulimt -n". Note that there's a type in that error message by the way. I ran:

ulimit -n 2048

...on the host (it was originally set to 1024) but that didn't seem to make any difference.

[vasily Levchenko]

It'd be better to attach the log files than paste whole or part of it.

[joncage]

VBox log including the too many files reference.

[joncage]

Added the log file from the offending virtual box. I've since upgraded to 3.1.6 but still have the same problem.

[joncage]

This happened again tonight. Shutting down and then re-starting the virtual machine from the linux command line appears to fix it at least temporarily.

[anonymous]

I am seeing this bug as well... Seems like the virtualbox service/driver is leaking file handles.

[Vadym Kononenko]

I've catch similary behaviour.

Steps to reproduce:

1. Create VM with 'RedHat' type.
2. Get 'ftp.linux.kiev.ua/pub/Linux/CentOS/5.5/isos/i386/CentOS-5.5-i386-netinstall.iso' ISO image and attach to newly created VM.
3. Try to set up CentOS through network from 'ftp.linux.kiev.ua/pub/Linux/CentOS/5.5/os/i386'
4. The installation process stops before half of packages were installed.
5. Do

   # ps ax | grep VB
   12934 ?        S      0:00 /usr/lib/virtualbox/VBoxXPCOMIPCD
   12940 ?        Sl     0:00 /usr/lib/virtualbox/VBoxSVC --auto-shutdown
   12953 ?        Sl    21:19 /usr/lib/virtualbox/VBoxHeadless --comment ung_RedHat --startvm e1dedf64-1234-4ecd-9ae0-55a24c18a52f
   

6. Do

   # cd /proc/12953/fd && ls -1 | wc -l
   1024
   

7. Do

   # ls -l1
   [skip]
   lrwx------ 1 root root 64 2010-12-31 16:42 994 -> socket:[73279758]
   lrwx------ 1 root root 64 2010-12-31 16:42 995 -> socket:[73273414]
   lrwx------ 1 root root 64 2010-12-31 16:42 996 -> socket:[73276111]
   lrwx------ 1 root root 64 2010-12-31 16:42 997 -> socket:[73273416]
   lrwx------ 1 root root 64 2010-12-31 16:42 998 -> socket:[73288562]
   lrwx------ 1 root root 64 2010-12-31 16:42 999 -> socket:[73273420]
   

8. Do

   # ulimit -n
   1024
   

[Vadym Kononenko]

9. After I made "VBoxManage controlvm ung_RedHat savestate" it told me about VERR_TOO_MANY_OPEN_FILES.

[Vadym Kononenko]

VMachineConfig-VBox-4.0.0

[jwal]

I have encountered a similar situation to konan.ukraine. I have a ulimit -n value of 1024 an my VM process has 1024 open file handles. The majority of these are sockets.

The reason I am posting is to supply some additional information that might help somebody debug this further. My VM does not actually require any external network connections and so I tried disabling the network adapter. My processes in the VM then completed without hitting the error. These guest processes, that seem to trigger a leak in open socket fds, are python scripts that are run from a vboxsf mounted shared folder but that access a web service on ​http://127.0.0.1:8002/ that is also a guest python script (using flask) running from a vboxsf folder. I have taken care to use the 127.0.0.1 IP address to avoid DNS and to disable any HTTP proxy configuration and yet disabling networking still seems to help me avoid this problem. It is not clear to me why VirtualBox is opening these sockets.

I have looked at the open sockets. readlink on the /proc/*/fd entries gives me a socket inode number which all seem to be unique. These can then be found as entries in /proc/*/net/udp. The lines look like this:

# head -n1 net/udp ; tail net/udp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops             
 4037: 00000000:B0EC 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 929088 2 ffff880092575080 0        
 4037: 00000000:A0EC 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 928818 2 ffff88008463f700 0        
 4045: 00000000:C0F4 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 926397 2 ffff8802213bdb00 0        
 4045: 00000000:E0F4 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 926387 2 ffff8802213bd400 0        
 4047: 00000000:B0F6 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 929834 2 ffff880097b78a80 0        
 4048: 00000000:B0F7 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 928927 2 ffff880165343480 0        
 4048: 00000000:E0F7 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 926555 2 ffff8801882abb80 0        
 4072: 00000000:C10F 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 927659 2 ffff88018d00f000 0        
 4093: 00000000:A124 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 928857 2 ffff88021fcc7700 0        
 4094: 00000000:8125 00000000:0000 07 00000000:00000000 00:00000000 00000000  1000        0 926558 2 ffff8801882ad780 0        

I don't know enough about these to be able to debug further at the moment. Perhaps somebody else can trace the leak further?

The networking mode of my VM is NAT and I have seen this leak both with and without the natdnshostresolver1 setting. I am using Ubuntu 13.04 "Raring". If this is a different issue I am happy to raise it as such, please advise.

[jwal]

I have just tried with internal networking instead of NAT and there is no leak. My working theory is that something in the NAT networking implementation is leaking UDP sockets. There is a possibility, of course, that there is a guest leak that is being passed on to affect the virtualbox host process itself.

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.