Vagrant: Too many open files - getcwd (Errno::EMFILE)

[thbar]

While doing vagrant up on a precise64 box with virtualbox 4.2.18 r88780 and vagrant 1.3.5, I'm getting these errors.

It occurs only if I try to use a synced folder using this (if I remove this, the issue disappears):

config.vm.synced_folder "projects", "/projects"

I did not include the full verbose log publicly because I'm concerned about leaking some client related data, but I could send it to you privately though.

[thbar]

I upgraded virtualbox to 4.3.0 and see the same issue. I also tried this but it didn't work:

config.vm.provision :shell, :inline => "ulimit -n 4048"

[sirupsen]

Seeing the same issue.

[manuelmeurer]

Setting the number of allowed open files to 4048 on the CL before calling vagrant up worked for me.
http://stackoverflow.com/questions/18808540/error-when-running-vagrant-up-too-many-open-files-getcwd-errnoemfile

[thbar]

@manuelmeurer thanks - it worked for me if I put the shell inline at the very top of the configure block; and even in that case, in some occasions, it will still fail. But thanks for mentioning this, since it now works 90% of the time :-)

[thbar]

On another project, I have to do ulimit -n 4048 from the CL to fix things, indeed.

[mitchellh]

Vagrant itself doesn't use many file handles (and when it does it closes them) so I'm unsure where this could be coming from. Without more info I'm going to close this since the workaround is so easy (just increase max files).

[cpjolicoeur]

It would be nice if the underlying issue on this could be resolved as this continues to be an issue. Even tho we can do the ulimit workaround, its just that, a workaround.

[mitchellh]

Yeah I can't reproduce this. It seems odd since I feel like I'm pretty good about file descriptors and Vagrant shouldn't use that many anyways. Would love more info.

[whomwah]

This is an issue for me too, which I've never had before I upgraded both Vagrant and VirtualBox. The ulimit fix does not work for me. I'm afraid I couldn't tell whether VB or Vagrant causing the problem :

• MacBook Air 8GB, 1.8 Core i5
• Vagrant 1.4.3
• VirtualBox 4.3.6 r91406
• Vagrantfile [ http://paste.ubuntu.com/6866105/ ]

Error Output [http://paste.ubuntu.com/6866112/]

PS It would appear that is the shared folders that are causing the issue on my setup.

[bjones]

It's still an issue apparently. https://gist.github.com/bjones/f2411b9b94ac5ff4483a
Oracle VM VirtualBox Manager 4.3.12
Vagrant 1.6.3

If it helps, I then did halt and reload and it worked.

[agis]

I too get this when doing $ vagrant up using Vagrant 1.6.3 on OS X 10.9.4.

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'puppetlabs/debian-7.4-64-puppet'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'puppetlabs/debian-7.4-64-puppet' is up to date...
==> default: Setting the name of the VM: test-box_default_1405346023035_89011
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
==> default: Forcing shutdown of VM...
==> default: Destroying VM and associated drives...
==> default: Running cleanup tasks for 'shell' provisioner...
==> default: Running cleanup tasks for 'puppet' provisioner...
/Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/subprocess.rb:42:in `pwd': Too many open files - getcwd (Errno::EMFILE)
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/subprocess.rb:42:in `execute'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/subprocess.rb:22:in `execute'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/driver/base.rb:372:in `block in raw'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/busy.rb:19:in `busy'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/driver/base.rb:371:in `raw'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/driver/base.rb:310:in `block in execute'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/retryable.rb:17:in `retryable'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/driver/base.rb:305:in `execute'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/driver/version_4_3.rb:241:in `read_forwarded_ports'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/driver/version_4_3.rb:490:in `ssh_port'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/provider.rb:67:in `ssh_info'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:367:in `ssh_info'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/communicators/ssh/communicator.rb:138:in `ready?'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/communicators/ssh/communicator.rb:62:in `block in wait_for_ready'
        from /Applications/Vagrant/embedded/lib/ruby/2.0.0/timeout.rb:66:in `timeout'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/communicators/ssh/communicator.rb:39:in `wait_for_ready'
        from /Applications/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/wait_for_communicator.rb:16:in `block in call'

My Vagrantfile:

$ cat Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "puppetlabs/debian-7.4-64-puppet"
  config.vm.provision :shell, path: "bootstrap.sh"
end

And the shell provisioning script:

$ cat bootstrap.sh
#!/usr/bin/env bash

ulimit -n 50000

sudo bash -c 'echo "deb http:/xxxxx wheezy main" > /etc/apt/sources.list.d/xxx.list'
sudo bash -c 'echo "deb http://xxxxx wheezy-backports main" > /etc/apt/sources.list.d/xxx.list'
wget -O - http://xxxxxxx | sudo apt-key add -
sudo apt-get update
sudo DEBIAN_FRONTEND=noninteractive apt-get install -q --yes --force-yes \
make git-core libffi-dev libgdbm-dev libncurses5-dev libreadline6-dev libyaml-dev \
zlib1g-dev openssl libssl-dev build-essential ruby

sudo DEBIAN_FRONTEND=noninteractive apt-get install -q --yes --force-yes \
libxml2-dev libxslt1-dev libcurl4-openssl-dev wdiff imagemagick nodejs

# do not generate gem documentation
echo 'gem: --no-rdoc --no-ri' > /home/vagrant/.gemrc

# cause puppetlabs/debian-7.4-64-puppet uses dash
# but we want bash
sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh

Using Vagrant 1.6.3 on OS X 10.9.4.

[ghost]

So I ran into this issue and used the workaround on my *host* terminal to get the machine to boot more than just one time (vagrant up ran fine once and only once before I upped my own host ulimit).

==> base_vm: Running provisioner: shell...
/Applications/Vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/util/subprocess.rb:42:in `pwd': Too many open files - getcwd (Errno::EMFILE)

[agis]

It seems that on OS X Mavericks the default ulimit -n was set to 200. Increasing it to 1024 did the trick.

[bendilley]

Further to @agis-'s comment, I can confirm that I also found it was the OS X host machine's ulimit -n that was too small, at 256. Upping it to 1024 (same as the Ubuntu default) did the trick. This can of course be added to ~/.bash_profile or equivalent.

[mcandre]

On my machine, ulimit reports unlimited, and I still see this "Too many open files" error anyway. Using macOS Sierra.

[jdub55]

"ulimit -n" is different from ulimit. More info here: https://docs.mongodb.com/manual/reference/ulimit/

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.