Re: Mongo on VirtualBox

[Stephen Steneker]

On Wednesday, February 13, 2013 10:02:51 PM UTC+11, Kyle Redelinghuys wrote:

Wed Feb 13 11:57:47 [initandlisten] options: { dbpath: "/vagrant/.meteor/local/db" }
Wed Feb 13 11:57:47 [initandlisten] Unable to check for journal files due to: boost::filesystem::basic_directory_iterator constructor: No such file or directory: "/vagrant/.meteor/local/db/journal"
Wed Feb 13 11:57:47 [initandlisten] Assertion: 13651:Couldn't fsync directory '/vagrant/.meteor/local/db': errno:22 Invalid argument

Hi Kyle,

The errors all appear related to your specified dbpath .. are you sure that /vagrant/.meteor/local/db exists in the VM and has appropriate permissions for your mongod to read & write files?

Cheers,

Stephen

[Kyle Redelinghuys]

Hi Stephen

Thanks for the response. But I don't believe this is the case:

vagrant@lucid32:/vagrant/.meteor/local$ ll
total 16
drwxr-xr-x 1 vagrant vagrant 4096 2013-02-13 11:23 ./
drwxr-xr-x 1 vagrant vagrant 4096 2013-02-07 11:25 ../
drwxr-xr-x 1 vagrant vagrant 4096 2013-02-13 11:23 build/
drwxr-xr-x 1 vagrant vagrant 4096 2013-02-14 06:54 db/

And:

vagrant@lucid32:/vagrant/.meteor/local$ ll db/
total 65556
drwxr-xr-x 1 vagrant vagrant     4096 2013-02-14 06:54 ./
drwxr-xr-x 1 vagrant vagrant     4096 2013-02-13 11:23 ../
drwxrwxr-x 1 vagrant vagrant     4096 2013-02-12 08:11 meteor/
-rw------- 1 vagrant vagrant 16777216 2013-02-13 11:23 meteor.0
-rw------- 1 vagrant vagrant 33554432 2013-02-12 08:17 meteor.1
-rw------- 1 vagrant vagrant 16777216 2013-02-13 11:23 meteor.ns
-rwxr-xr-x 1 vagrant vagrant        0 2013-02-14 06:58 mongod.lock*
vagrant@lucid32:/vagrant/.meteor/local$

The lock file is there due to Meteor failing to start. Even after removing this file, the error message is the same.

I could try change ownership, but the vagrant user is root so this shouldn't be an issue. From what I have read it might have to do with how VirtualBox mounts directories, those related to mongo specifically, so would relate to the actual vagrant user.

Any thoughts?

Thanks

[Kyle Redelinghuys]

To be sure, I changed the permissions to 777 on all files in the db/directory, and still get the same error.

[andy]

I'm just getting started with Vagrant (and haven't used it w/ mongo but planning to), but wondering - are any of those links in .meteor symlinks? Apparently that can be an issue: http://blog.liip.ch/archive/2012/07/25/vagrant-and-node-js-quick-tip.html

Also, here's a related SO post from Dec 12 (I didn't realize Mongo doesn't like NFS): http://stackoverflow.com/questions/13676868/issues-with-meteor-app-on-vagrant-share

I was running Mongo on a CentOS VM the other day for a quick test and it didn't have any issues, but it was installed directly into the VM...

Sorry, probably no real help.

andy

[Stephen Steneker]

 

I could try change ownership, but the vagrant user is root so this shouldn't be an issue. From what I have read it might have to do with how VirtualBox mounts directories, those related to mongo specifically, so would relate to the actual vagrant user.

Hi Kyle,

I've tried to reproduce this with VirtualBox 4.2.6, Vagrant 1.0.6, Meteor 0.5.6-1, and MongoDB 2.2.1 (installed by Meteor).

Seems to run OK as the 'vagrant' user assuming that the ownership on /vagrant/ is vagrant:vagrant.

Can you try 'sudo chown -R vagrant:vagrant /vagrant/.meteor' ?  If that doesn't work, can you try with your meteor app in a directory other than /vagrant?

I can only trigger the same error by having incorrect directory permissions/ownership (tried with a symlink as well).

It's possible your virtualbox/vagrant install set up the mount points differently than mine.  What specific versions of VirtualBox, Vagrant, and Meteor are you using?

Cheers,

Stephen

[Kyle Redelinghuys]

Hi Andy

Thanks for the response. I think Meteor might symlink to a local copy of mongo/node, which might very well be causing these issues. And I've also seem the file system issues, but wondering if there is a workaround or solution to it. Installing the project directly on the VM instance is not a feasible option.

Thanks

[Kyle Redelinghuys]

Hi Stephen

It is odd that you couldn't reproduce it. I am running all the same versions that you are (vbox 4.2.6, vagrant 1.0.6, meteor 0.5.6 and the default mongo install). I also had mongo install on the VM, but removed it and reinstalled and there is the same behaviour.

I symlinked to the vagrant directory from within the VM and tested, and got the same result. I also chowned every folder in the meteor app directory to vagrant:vagrant. Permissions are fine as well.

I am certain that I could get this to run if I install it within the VM, but that is not a feasible solution. What intrigues me is that you did not have any problem.

I will install a default Meteor app and vagrant up to another box. What VM iso did you use for vagrant? Is your local machine 32 or 64bit?

Thanks for the help.

[Stephen Steneker]

It is odd that you couldn't reproduce it. I am running all the same versions that you are (vbox 4.2.6, vagrant 1.0.6, meteor 0.5.6 and the default mongo install). I also had mongo install on the VM, but removed it and reinstalled and there is the same behaviour.

Hi Kyle,

Sorry, I rechecked and my /vagrant mount point was bogus from earlier testing (restarting via the VM manager doesn't mount /vagrant as a shared folder).

There are definitely issues using VirtualBox vboxsf (or nfs) mounts with MongoDB.

A few possible workarounds to consider:

 1) Login to the VM (`vagrant ssh`) and symlink .meteor/local/db/ to a directory that isn't a shared dir (eg ~/db).  This should allow you to share your app between systems and have a database local to the VM.

 2) Run meteor using an external MongoDB (i.e. one running in the host environment rather than the VM).
 MONGO_URL=mongodb://192.168.1.123:27017 meteor 

There appear to be more fiddly bits to get Meteor to happily run from shared folders, so installing in the VM would be the least painful path (though as you noted, not feasible for your requirements).

Cheers,

Stephen

[Marcus Putz]

Hey!

I had the same error as described.

Linking to the home directory is my used solution. But it's just a workaround.

/Marcus