VirtualBox

Ticket #6464 (new defect)

Opened 4 years ago

Last modified 12 months ago

uTorrent fails with "too many open files"

Reported by: joncage Owned by:
Priority: major Component: shared folders
Version: VirtualBox 3.1.4 Keywords:
Cc: Guest type: Windows
Host type: Linux

Description (last modified by Hachiman) (diff)

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.

Attachments

VBox.log Download (120.1 KB) - added by joncage 4 years ago.
VBox log including the too many files reference.
ung_RedHat.vbox Download (6.7 KB) - added by konan.ukraine 3 years ago.
VMachineConfig-VBox-4.0.0

Change History

comment:1 Changed 4 years ago by Hachiman

  • Description modified (diff)

comment:2 Changed 4 years ago by Hachiman

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

Changed 4 years ago by joncage

VBox log including the too many files reference.

comment:3 Changed 4 years ago by joncage

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

comment:4 Changed 4 years ago by 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.

comment:5 Changed 3 years ago by john.doe

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

comment:6 Changed 3 years ago by konan.ukraine

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
    

comment:7 Changed 3 years ago by konan.ukraine

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

Changed 3 years ago by konan.ukraine

VMachineConfig-VBox-4.0.0

comment:8 Changed 12 months ago by 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.

comment:9 Changed 12 months ago by 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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use